It gets tricky when you want to say “allow this particular tool to have a little more access.” Like allow the codex client to access the GPT API but not some random other site the LLM learned about. Or like letting git write to .git to commit changes but don’t let something install git hooks. Or allow downloading certain packages/versions from a site like PyPI, or allow certain operations on certain GitHub repos in a way that doesn’t line up with how you can configure an access token.
Not if the harness applies an OS-level sandbox to the process, as Codex does.
https://learn.chatgpt.com/docs/sandboxing?surface=cli
Unfortunately it was possible in codex too, until recently.
https://github.com/openai/codex/issues/5237
on linux, thats this: https://ubuntu.com/security/notices/USN-8288-1
No, you need to apply the sandbox to the codex process itself. Codex does not do this.
It gets tricky when you want to say “allow this particular tool to have a little more access.” Like allow the codex client to access the GPT API but not some random other site the LLM learned about. Or like letting git write to .git to commit changes but don’t let something install git hooks. Or allow downloading certain packages/versions from a site like PyPI, or allow certain operations on certain GitHub repos in a way that doesn’t line up with how you can configure an access token.