> 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.