Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Sound like snake oil. How would this work? The app that the agent is developing needs access to the file, so access to it cannot be blocked. Just because read_file can not access it (I think current harnesses prevent reading .env files already), does not mean the contents will never be seen by the model.by planb
- Out of scope, learn cybersecurity. A simple concept such as users and permissions solves this problem.
Regardless of what technique you use, you need a deputy, you wouldn't ask an employee not to go into the vault, right? You would lock the vault. Well you can ask the employee not to go into the vault, and you can also ask codex not to use certain files, but if you need more certainty, you need to it outside.
The issue seems to be that people want to ask their agent to do everything, they want the agent to lock themselves out of some system, they want the agent to install itself, they want the agent to write their prompts so they don't have to write them. At some point there's some things YOU have to do, and you have to DO them.
by TZubiri - To avoid the risk of exfiltration, we need to stop using .env for security. API keys needed when working in a repo should be handled by a proxy like ssh-agent, and we need something better than bearer auth.by skybrian
- Sounds like user error to me. Codex gives an llm a tool to allow it to use shell in the context of the host and user in which it is running. If a resource is sensitive, and accessible in that context, then the user is doing something wrong. Would you change your practices if you treated your coding agent as an untrusted human ssh'd under the identity you use for it?
In any case. There are solutions in the comments on the issue, as well as this hn thread.
by agentdev001 - I recently got the tool I use to orchestrate agents in (remote/secure) devcontainers open-sourced at work to solve this properly: https://github.com/nvidia/rumpelpod
As others here have pointed out, it's exceedingly unlikely that a blocklist like proposed in the issue would ever be complete. You shouldn't allow agents direct yolo-access to your machine if it has sensitive data.
Codex works particularly well as a remote agent harness because of its client-server architecture: The server component runs in the container, which might be remote, while the client runs locally. So, in contrast to e.g. the claude cli where the frontend also runs remotely, there's no lag when you write/edit prompts.
by mbid - Files that codex and any other coding agent has access to, should be opt-in NOT opt-out. I think codex is not the right layer to solve this if you want a sane(one-click) UX. We built our own internal sandboxing-terminal around claude and codex. Where a user-configured base-folder with low-risk code and creds is COPIED into the sandbox BEFORE new session creation. There were many other UX related reasons to build our own terminal. Can share more if anyone is interested.by nikhilsimha
- Hopefully they never actually implement this pointless feature because it will only give people a false sense of security given the unpredictable nature of LLMs. How could something like this even be enforced?
People just need to learn how to use the tools their system already provides them. i.e., chmod
by petcat - You can do this now: change the file permissions such that the user you run codex as can't read them, or run codex in a container without those files mounted.
If you don't do that, the agent will be able to incidentally upload them. What if the model runs "rg foo", and one of those files contains the string "foo"? It uploads the tool output, which includes the file contents.
And so, the only solution is to make it so the codex process is unable to access those files, hence using a container, or unix permissions, or deleting the files. Which you can already do.
I imagine this isn't resolved primarily because people expect it to apply to bash tool use, not just the "read" and "edit" tools, and people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly.
by TheDong