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.
The Codex bug tracker is a great insight into how wide the knowledge gap seem to be between users. The issue where people ask them to add back /undo or whatever it is instead of just learning to use git, probably reached 100 comments at least by now. People seemingly don't really understand the computers they use on a daily basis, and refuse to learn too.
We managed to generate probably-correct code, which can then be probably-corrected recursively to get to something that runs (usually).
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 suspect most people don't even know there's a there there.
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.
When I was an undergraduate biology student in 1991 a suitemate told me I should go to some desk in some building over by Muir and get an account on the VAX. There were strange rooms all over campus that were open 24/7 and were loaded with green and amber screen terminals with integrated keyboards. Lots of sessions for CS lectures were held in these rooms and there was always interesting notes on the white boards (most rooms still had black boards or green boards, but think the chalk was too dusty so these rooms usually had the white boards.
Once I saw an instruction that was circled with an arrow pointing to is that said:
man man
man -k -or- apropos
and that was how I learned about computers.
I just typed `man man` in a terminal on my Mac, and luckily its still there.
The difference is that git is a traditional programming tool which executes deterministically.
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.
I don't think I've ever seen it used. I think the idea was back in the day when you wanted to let a user have a shell login (because that's the only way you could use a shared computer) but wanted to confine them to a specific directory and prevent them running anything that wasn't in the pre-defined PATH that you set for them.
.gitignore doesn't have the same security implications.
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.
I could imagine perhaps some system which rather than denying access might instead replace the key material from your .env key with "** redacted. This key material can be used via make, but can never be exfoltrated directly **" whenever that key is seen heading out towards the network...
OnePassword can do something like this where you put references to a path there instead of the key material, and then you wrap the invoke command with their CLI and it replaces them. So your local env file never has anything sensitive. A malicious agent could still exfiltrate if you give it access to debug tools on the running code though.