alt Hacker NewsYou 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.
Replies
Just be aware that AI agents will explore alternate means of accessing said files: https://news.ycombinator.com/item?id=48348578
While this is true, there is also a layer in the harness between the output of _any_ tool output (eg stdout or hand-rolled tools) and the LLM. A tool could read the file but then the agentic harness could redact the output before returning it back to the llm if any of the contents matched the file contents. We do something similar in Plotly Studio where we check the entropy of strings in the user input and flag & redact any high entropy strings to the user as “potential credentials” thay the user might have inadvertently copied and pasted into the prompt before sending to the llm.
There are ways around this - the llm can always be clever by invoking tools to read the file contents in a different way than the direct file contents - but this is all to say that the agentic harness layer _does_ allow for deterministic logic in between tool output and the LLM requests.
Sandboxing is a solved problem, there are dozens of providers of firecracker instances to run your agent in.
The problem to be solved is how do you define task-specific least privilege versions of your coding agent.
If you're not sandboxing your agent, everything on your computer is waiting to be exposed.
Assuming that file permissions will save you is naively dangerous.
> 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.
Also, why would they add a feature to prevent data collection, if the data makes the company even more valuable and you might even get good deals from the current government if you provide the access for this data?
Yes, this was solved decades ago. How do you stop a human from reading one of your files?
chmod 600[dead]
100% this. The idea that Codex should enforce this is putting the security boundary at the wrong layer. If you don’t want codes to access something, make it so it doesn’t have access.