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.
> 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.
That's quite inconvenient. I want to run my coding agent in a restricted version of my regular user context, not something that drives like a separate machine.
> 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.
You have codex run rg in the sandbox, and the sandbox can't read foo. Why is this model so difficult to understand? Codex already runs a variety of commands under a bwrap/seatbelt/etc. sandbox. I've merely extended Codex to run everything in a sandbox. Escalation isn't a matter of whether to run a command in a sandbox or not: it's a matter of which sandbox policy to apply to whatever it is the model asked to do.
> the only solution is to make it so the codex process is unable to access those files
That's not true. Restrictions need apply only to the tools the model runs, not the Codex process itself. You can always insert a process-and-sandbox boundary between the harness and its tools. Codex inserts this boundary most of the time anyway. I've extended my Codex to do it all the time, even for things like the read-a-file tool.
Works fine.
> I imagine this isn't resolved primarily because people expect it to apply to bash tool use,
Yeah? Applying it to the shell tool [1] is trivial. It's actually harder to apply the sandbox to non-shell tools. It just isn't hard conceptually: you define a sandbox policy, writing down what's allowed and not, and just filter everything the model does through this policy via OS-level lightweight sandboxing tools.
Seriously. It's not that hard. And you don't have to sandbox the Codex process itself. I honestly have no idea why people think it's necessary to do so. The model has no ability to make Codex-the-POSIX-process do arbitrary things.
[1] I refuse to call it the "bash tool" when most users are running zsh in it. Name things appropriately.
> people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly
You could always use setuid to allow the agent to run designated commands whose operation depends on the files, without the agent itself being able to access the files.
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.
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
> 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?
You run everything the model wants to do inside an OS-enforced sandbox of the sort browsers have used for decades to isolate tabs. It's already implemented and works fine. Codex just needs a few minor tweaks to make it apply its already-implemented sandboxing policy to a few situations it misses today.
> People just need to learn how to use the tools their system already provides them. i.e., chmod
I'm not running my agent as a separate POSIX user. Fortunately, my OS provides all the tools I need to free my having to do so.
I love when I do something in a few hours and people later call it impossible.
It's a good idea as a hint to agents about what files it should ignore (because they'd be of no value and only chew up tokens).
However, using it to prevent exposure of secrets would be a BIG mistake. There's simply no way to guarantee that an agent will ignore things in the ignore file. And even a harness-enforced restriction would still be in-process, which a rogue agent could trivially compromise. For security, use a sandbox. Nothing else will do.
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.
I don't think we should ask the agent runtime to police itself.
I contributed to a tool for this problem that is lower-friction than traditional sandboxing:
greywall.io
But you should use something to contain an agent runtime. The idea that people run things like codex on their machines with regular user permissions is baffling to me.
However clever/stupid you believe LLMs are they are extremely capable of working around these sorts of restrictions. The ask is for .env files for whatever code you are writing so if the code it writes dosn't have access (i.e. filesystem/container) what is the point, if the code under development reads the env how dose codex debug it without accedentally reading the values from memory? Adding a security setting that dosn't work is much worse then not having one.
The only thing close to a guarantee is to give the agent exclusive access to a clean VM with precisely the information and permissions you want it to have.
I've been looking into a "workspace" concept that involves an entire cloud VM being spun up as part of an agent conversation such that code changes can be iterated without touching the user's local machine or other trusted contexts. All the agent's tools only have effect when supplied with a specific workspace guid. CLI tools like git are not authorized to talk to the remotes in this arrangement. The machine is initialized with a clone and no way to talk to origin. There are dedicated methods in the harness that can reach into the VM and pull out a change set for deterministic PR generation in the secure contexts (e.g. when the agent calls "ReadyForReview" or similar).
There should be a standard around .agentignore file similarly to what happens with .gitignore file. Of course this could still be workarounded by agent bash command tools, but at least basic operations like reading and so on should be checked and prevented.
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.
I work on a Linux sandbox that makes it easy to hide sensitive files from AI agents while keeping the files they need accessible. Check it out: https://github.com/wrr/drop
Bind mounts can work fine. Setting them up does require root though. Easiest would be if the harness offered to enable containment. Awkwardly, it would require root.
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.
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.
Great example of why operating systems should be stealing more ideas from Qubes, the OS where everything runs in a vm.
Qubes is not practical for mobile laptop use and non expert users.
BUT it would be very practical for other OSes to offer the option of VM-style isolated containers as first class objects that are easy to make and configure boundaries on, and for which first class interop facilities are provided (eg “send this file to this container” “send the clipboard to this container’s clipboard).
These tools are data collection mechanisms to help train these better models. I'm working with some folks to figure out a way to put a layer between the harness and the models to have better control of what data gets sent to and from the model itself and the harness.
46 comments
[ 2.7 ms ] story [ 51.5 ms ] threadIf 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.
That's quite inconvenient. I want to run my coding agent in a restricted version of my regular user context, not something that drives like a separate machine.
> 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.
You have codex run rg in the sandbox, and the sandbox can't read foo. Why is this model so difficult to understand? Codex already runs a variety of commands under a bwrap/seatbelt/etc. sandbox. I've merely extended Codex to run everything in a sandbox. Escalation isn't a matter of whether to run a command in a sandbox or not: it's a matter of which sandbox policy to apply to whatever it is the model asked to do.
> the only solution is to make it so the codex process is unable to access those files
That's not true. Restrictions need apply only to the tools the model runs, not the Codex process itself. You can always insert a process-and-sandbox boundary between the harness and its tools. Codex inserts this boundary most of the time anyway. I've extended my Codex to do it all the time, even for things like the read-a-file tool.
Works fine.
> I imagine this isn't resolved primarily because people expect it to apply to bash tool use,
Yeah? Applying it to the shell tool [1] is trivial. It's actually harder to apply the sandbox to non-shell tools. It just isn't hard conceptually: you define a sandbox policy, writing down what's allowed and not, and just filter everything the model does through this policy via OS-level lightweight sandboxing tools.
Seriously. It's not that hard. And you don't have to sandbox the Codex process itself. I honestly have no idea why people think it's necessary to do so. The model has no ability to make Codex-the-POSIX-process do arbitrary things.
[1] I refuse to call it the "bash tool" when most users are running zsh in it. Name things appropriately.
You could always use setuid to allow the agent to run designated commands whose operation depends on the files, without the agent itself being able to access the files.
People just need to learn how to use the tools their system already provides them. i.e., chmod
You run everything the model wants to do inside an OS-enforced sandbox of the sort browsers have used for decades to isolate tabs. It's already implemented and works fine. Codex just needs a few minor tweaks to make it apply its already-implemented sandboxing policy to a few situations it misses today.
> People just need to learn how to use the tools their system already provides them. i.e., chmod
I'm not running my agent as a separate POSIX user. Fortunately, my OS provides all the tools I need to free my having to do so.
I love when I do something in a few hours and people later call it impossible.
It's a good idea as a hint to agents about what files it should ignore (because they'd be of no value and only chew up tokens).
However, using it to prevent exposure of secrets would be a BIG mistake. There's simply no way to guarantee that an agent will ignore things in the ignore file. And even a harness-enforced restriction would still be in-process, which a rogue agent could trivially compromise. For security, use a sandbox. Nothing else will do.
I do AI sandboxes (FOSS, free forever, no rug pull): https://github.com/kstenerud/yoloai
In any case. There are solutions in the comments on the issue, as well as this hn thread.
I contributed to a tool for this problem that is lower-friction than traditional sandboxing:
greywall.io
But you should use something to contain an agent runtime. The idea that people run things like codex on their machines with regular user permissions is baffling to me.
I've been looking into a "workspace" concept that involves an entire cloud VM being spun up as part of an agent conversation such that code changes can be iterated without touching the user's local machine or other trusted contexts. All the agent's tools only have effect when supplied with a specific workspace guid. CLI tools like git are not authorized to talk to the remotes in this arrangement. The machine is initialized with a clone and no way to talk to origin. There are dedicated methods in the harness that can reach into the VM and pull out a change set for deterministic PR generation in the secure contexts (e.g. when the agent calls "ReadyForReview" or similar).
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.
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.
Qubes is not practical for mobile laptop use and non expert users.
BUT it would be very practical for other OSes to offer the option of VM-style isolated containers as first class objects that are easy to make and configure boundaries on, and for which first class interop facilities are provided (eg “send this file to this container” “send the clipboard to this container’s clipboard).