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.
It’s not like gitignore should be independent from git
It’s a different mental model than a first party solution to “ignore” files.
Though really I’m skeptical that much corporate info is secret for competitive or privacy reasons.
Mostly it seems to be for liability / discovery reasons. Which are still legit of course, but ideas are a dime a dozen and every company has more than they know what to do with. It’s the resourcing and execution that are hard.
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?
chmod 600Call the police!
In any case. There are solutions in the comments on the issue, as well as this hn thread.
People just need to learn how to use the tools their system already provides them. i.e., chmod
But apparently, even if implemented, that's not how it works!
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.
Edit: would love a couple of pictures/video of how you use it. I kind of get the idea, but it seems like more hassle then it would be worth?
Your comment of codex makes it seem like I might be missing something tho.
Have you tried running `rumpel codex foo123` in one of your repositories, asking it to commit something, then `rumpel merge foo123` to get the changes back to your local checkout? Use a different terminal for the merge command, or detach from the codex session with `ctrl-a d`. You can also look at the commit first with `rumpel review foo123`, or get a shell inside the agent environment via `rumpel enter foo123`.
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).
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
So they're following best practice, not committing secrets but agents running locally can still see them even if sandboxing to the working directory.
I've taken to storing configs using XDG_CONFIG_HOME and have the app auto resolve them by convention or take a cli arg to specify the config path. All secrets are in files, not env vars.
That way when using sandboxing the agent can never see the configs or secrets as outside the working directory.
Makes me think of docker secret where the secrets are exposed as files and accessable only from inside the container.
If the development environment uses docker then thats a solution too I guess
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.