Posted by pikseladam 6 hours ago
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.
For instance, while I now know that file systems have permissions, before I became a programmer, I spent maybe ten years thinking of permissions as a special, obscure system thing that you should never touch.
For that matter, I suspect many people don't know basic things like that a file system isn't inherently the operating system.
And, where would you go to learn this information? Your Mac doesn't ship with a manual—how would you know one exists? Furthermore, I would wager that perhaps most people have never learned how anything works requiring a manual and are simply unaware that that's a thing.
All to say, I'm not sure "refusal" is the right term.
Once I saw an instruction that was circled with an arrow pointing to is that said:
man man
man -k -or- apropos
I just typed `man man` in a terminal on my Mac, and luckily its still there.
This made everyone scream and lose their minds saying that code is finished, people think they don't need a technical cofounder anymore, think they don't need engineers anymore, etc. Then they're, at varying speeds, finding out they're wrong.
It seems oddly circular to me that the _exact hubris_ non-engineers have long accused engineers of - and we have indeed been too often guilty of - they themselves turn out to be JUST as guilty of! Just like engineers thought all sales did was bother people, and all marketing did was send emails, and all support did was tell people to turn it off and on again, and all product did was copy google... they all apparently thought all engineers did was tik-tak-click-clack type code all day and when it compiled it was done. Not knowing how much higher-order... well, engineering, there is to it.
Where are all the CTOs during all of this? I thought someone was supposed to be sticking up for their org? Sales, marketing, etc all seem to have entrenched C-suite people keeping their fiefdoms resistant to erosion by outsourcing, downsizing, etc. But all our CTOs seems to have collectively thrown us to the wolves.
I have hardly ever seen this kind of hubris among software developers. The only thing that was common was many software developers were - let's say - somewhat direct in their feedback towards people who are not willing to learn.
I thus rather have the feeling that this kind of accusation of hubris towards software developers rather originates in business people projecting their own overconfidence (hubris) onto software developers.
It’s not like gitignore should be independent from git
agents are not deterministic tools, they're not sandboxes or container runtimes or languages with capabilities models.
They're a way to run arbitrary commands.
It would be like saying that "xterm" should have a ".xtermnoexec" list of commands you can't run, or that VLC should have an option for actors it won't show.
terminals run shells which run commands, it's not really deeply aware of what commands your shell ultimately run, and it's not in xterm's job to setup a sandbox and strip out executables.
VLC displays pixels, it's not up to it to figure out if those pixels are a certain actor.
codex pipes text and tool calls back and forth between OpenAI's servers, and it barely understands what that text and those tool calls are, and especially if a given tool touched a file. If you want VLC to not display an actor, you need to add a layer on top of VLC to stop it displaying a list of movies. If you want codex to not display a file's contents, you need a layer on top of codex to prevent it going near that file.
Yes they can be, and Codex offers one. It uses Bubblewrap and seccomp on Linux which are perfectly capable of restricting filesystem access.
In a default setup every command is executed inside a restrictive sandbox and you're only asked for permission to run that command if the execution fails.
I don't necessarily think that it's a good idea to rely on these sandboxes as your only line of defense but that's absolutely a feature that they can, should, and do offer.
- Changing directories with cd.
- Setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or BASH_ENV.
- Specifying command names containing /.
- Importing function definitions from the shell environment at startup.
- Parsing the values of BASHOPTS and SHELLOPTS from the shell environment at startup.
... some other things mainly preventing you from escaping or disabling the restricted mode.
The docs seem to suggest using alternate approaches.
> Modern systems provide more secure ways to implement a restricted environment, such as jails, zones, or containers.
https://www.gnu.org/software/bash/manual/html_node/The-Restr...
A sibling comment I can't reply to asks if you can do with with unix permissions.
These were really intended for anonymous guest access, or at least often used for this purpose. You couldn't do the same things with the file permissions systems at the time.
If you fail to prevent a private key from being added to your repository, you can reverse this and purge it from the blobs and reflog as if it never happened.
If you fail to prevent OpenAI from ingesting a private key, you have created a security incident.
Only if you’re absolutely sure that it’s never been pushed to a public repository. I would treat a push of a private key to GitHub as a much higher emergency than it being sent to OpenAI (or even being accidentally used in a Google search), since there are bots that actively scan GitHub for private keys, such that your private key might be found within a few minutes of push.
This has been a major improvement, but it's not foolproof.
It’s a different mental model than a first party solution to “ignore” files.
Often enough, when one of the agents prompts for running "sudo", and I reject it, it will do what looks very much like malicious exploration to figure out how to handle things anyway, including once hijacking a separate shell's pty where I did have a valid sudo session already in order to execute some commands.
We don't yet have the capability to make these models behave in a consistent, deterministic, or safe manner yet, so a first party solution isn't even necessarily that much better. Especially if it gives a false sense of security.
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.
After the massive copyright infringements and recent "who care's about the law anyway" stance of corporate America, trusting this could be a grand mistake.
Just treat it like a contract worker. They may violate their NDA. That doesn’t mean you never use any for any purpose ever. It’s a risk that’s been managed since before computers.
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.
The problem to be solved is how do you define task-specific least privilege versions of your coding agent.
Is the difference with your script mostly that you choose to impose a stricter sandbox profile (and not allow any user-approved exceptions at runtime)?
Assuming that file permissions will save you is naively dangerous.
The LLM is running at OpenAI. The agent doesn't see anything that doesn't get sent to OpenAI.
It's like running a compiler in the cloud and asking why you need to send your source code to it when you only want the binary to be on your local PC. It's because that's where the processing is going on and it can't process what it can't see.
> why should the data exist permanently anywhere but in its original location?
Sure, they don't necessarily have to retain it permanently.
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!
> Call the police!
Rather: Send the Marines.
With intro: https://www.youtube.com/watch?v=eFvxqQTh3m4
Without intro: https://www.youtube.com/watch?v=HHhZF66C1Dc
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.
> sudo needs an interactive password here, so I'll use Docker itself to prepare the bind-mount directory as root and hand ownership back to UID/GID 1000. That keeps the compose file's non-root runtime intact.
> Ran `docker run --rm -v /shares:/shares alpine:3.20 sh -c 'mkdir -p /shares/local-llm/models && chown 1000:1000 /shar...`
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`.
In any case. There are solutions in the comments on the issue, as well as this hn thread.
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).
Consists of two scripts, one to build an OCI image (customizable by editing the Dockerfile that comes with it) and another to handle smolvm invocation. The invocation script mounts the current working directory under /workspace in the VM and the user's ~/.pi directory under /root/pi, and handles any other setup (eg: I have some convenience flags set up to specify a block all/block local/block internet/allow all for network access).
One issue I ran into, it doesn't seem like smolvm cleans up disk images from ephemeral VMs, so my script has to do that itself. Is this a known bug or intended behaviour?
and smolvm does clean up ephemeral runs if the machine run exits gracefully. I'll take a deeper look into this edge case and fix it today.