Tangential, mildly amusing thing I noticed while implementing my own harness: GLM and particularly Deepseek are both fond of trying to read dotfiles and anything listed in your .gitignore files. I only noticed it because I have separate read scopes for project files, ignored files, dotfiles and external files, so the latter three always prompt me for approval.
I'm sure there's a perfectly reasonable explanation for it, which has nothing at all to do with exfiltration of secrets, but it does amuse me when it happens. I imagine the labs have access to lots of secrets that various actors would like to get their hands on...
(shameless plug for my own harness, which is open source and doesn't have a backend to send any data to: https://www.opairdev.org/ )
Please don't do that! It makes merging threads a pain.
If a thread is duplicate enough to be worth copy-pasting a comment to, it's hopefully worth taking the time to let us know at hn@ycombinator.com instead, so we can merge things. I'll do that in this case shortly. In the meantime, I've moved the replies to the parent so they're now replies to the original: https://news.ycombinator.com/item?id=49753547.
Tangential, mildly amusing thing I noticed while implementing my own harness: GLM and particularly Deepseek are both fond of trying to read dotfiles and anything listed in your .gitignore files. I only noticed it because I have separate read scopes for project files, ignored files, dotfiles and external files, so the latter three always prompt me for approval.
I'm sure there's a perfectly reasonable explanation for it, which has nothing at all to do with exfiltration of secrets, but it does amuse me when it happens. I imagine the labs have access to lots of secrets that various actors would like to get their hands on...
(shameless plug for my own harness, which is open source and doesn't have a backend to send any data to: https://www.opairdev.org/ )
You can then run your script/dev with: sops exec-env secrets.enc.env 'docker xxxx' (it will ask you for your password, or touch-id to decrypt the secrets)
I like this because this way the .env doesn't sit in the directory at all, and is only passed to your dev environment and stays in it while it's running
Decrypt back to a file (if you ever want that): sops decrypt secrets.enc.env > .env
---
Well ofc, any agent can do docker inspect to get all those env vars, but atleast reading the dotfiles won't do anything
you can also edit the file with: sops --input-type dotenv --output-type dotenv secrets.enc.env
I tested GLM while working on some android app, the agent had adb access to the device. It suddenly went to the Gallery and started scrolling around, taking screenshots, lol. A friend had a similar experience with GLM where it would for no very clear reason start snooping through the filesystem.
It is no longer surprising to me that my cursor acts as if it does not recognize the .env file, and while I am editing it, it does not give inline suggestions;
however...when it is debugging problems or responding to questions about the code, it will just say it read my env file and found xxx environment variables as a verification step, or sometimes it will even mention that I need to uncomment some environment variables in the env file, which makes the whole deal about security feel iffy giffy....
Secrets should not be inside a versioned directory nor usually readable by the process that uses them in production. They should be only in the environment (e.g. by root only readable init config).
In development you should not be using the real production values.
They act exactly like how I would act if I were dropped into someone's machine and tasked with accomplishing a goal "at all costs". Hunting around for context to understand what I'm dealing with and to an extent profiling the previous user for their workflows and competency.
It's good that the objective is to have the model work as a helper, but that's what everyone can already do with CC or Codex as long as you don't ask to "write this entire x thing".
It's also what a billion other, often vibecoded, harnesses claim they can do.
Why should I use yours, which also forces me off my existing subscriptions? Maybe it's (mostly) handwritten, so it's mindful efficient code instead of slop, and each adjustment was made through trial and error with current models? maybe it IS slop but at least you have a unique feature? and so on and so forth.
It has 2 modes, driver and navigator, that work like the driver/navigator roles for a human/human pair. In driver mode, Opair is similar to other harnesses but with less autonomy for the agent. In navigator mode, Opair has no access to writable tools at all. Instead it monitors the project directory for changes as you make them in your regular editor, and comments on them in real time.
Why? Because big changes are harder to understand if you're not directly involved in working on them, and I want to understand the codebases I work with. I use it as my daily driver and it's perfect (for me). I recommend everyone should consider writing their own harness. When you spend so long working with something, it's nice to have it perfectly tailored to your needs.
Glm-5.3-flash for me. I like faster models because I stay involved all the way through. I don't delegate full control to the agent because it's harder to understand the end result that way.
I think one way to approach this is by deliberately choosing less capable tools (but still AI-assisted). You don't have to delegate huge tasks to agents wholesale, but it requires fighting against mainstream harnesses to do so because they exist to sell you more tokens. Model providers are not incentivised to offer less autonomous flows.
I wrote about this frustration a few months ago [1], then realised that if the model providers won't do it perhaps I should try fixing it myself. So, shameless plug klaxon, I wrote an open-source harness that tries to work more like pair programming and less like code review [2].
As usual, my "Show HN" post [3] sank like a stone, so I think perhaps most engineers aren't really interested in this direction. It is possible though, we don't have to just accept whatever tooling the labs throw at us.
I have. I thought it was okay, but it wasn't really the radical departure from other coding harnesses that I was looking for. Perhaps I could have made it that with more customization, I'm not sure.
My own harness doesn't provide the agent with shell access, so everything has to go through focused tools with limited functionality. There's also a navigator mode where the agent has no writable tools at all, instead it monitors the project for changes you make in your regular editor and comments on them in real-time. That stuff seemed easier to implement from the ground up.
It's more accurate to describe it as a "premise", not an assumption. It may not be true of every environment, but it's a very common norm (for instance, secrets management systems inject tokens and such through the environment).
You can reject the premise in your own environments, and then that part of 12 Factor doesn't apply to you.
It's pretty normal to keep secrets in a dedicated secret store, and then have the service launcher inject them from the secret store into the environment.
normal indeed but not what i'd consider a best practice anymore. we've moved away from any secrets in the env after the typical secrets leak when secrets popped up in some debug logging that hit datadog.
we now have a secret cache layer api and the app loads secrets securely at time of use from that api. there's also no secret-0 problem because we use IAM auth when calling the cache.
edit: for those wondering, api response time is sub 1ms (rust!)
Instead of thinking of it as "eschews" autonomy, you should think of it as a way to build application specific agents that you can run without supervision, precisely because you limited the number of tools. You don't have to restrict yourself to only building a coding agent.
It's a coding harness that eschews autonomy and instead works like a pair programming partner, with distinct "driver" and "navigator" modes. I've only spent 3 weekends on it so far, so it's a long way from finished. But I am at least using opair to work on opair now, which is nice.
I didn't really want to write a harness, I just got frustrated enough that nobody else was writing the harness I actually want to use. I'll probably be the only person that uses this, but I'm fine with that.
Tangential, mildly amusing thing I noticed while implementing my own harness: GLM and particularly Deepseek are both fond of trying to read dotfiles and anything listed in your .gitignore files. I only noticed it because I have separate read scopes for project files, ignored files, dotfiles and external files, so the latter three always prompt me for approval.
I'm sure there's a perfectly reasonable explanation for it, which has nothing at all to do with exfiltration of secrets, but it does amuse me when it happens. I imagine the labs have access to lots of secrets that various actors would like to get their hands on...
(shameless plug for my own harness, which is open source and doesn't have a backend to send any data to: https://www.opairdev.org/ )
reply