A good but altogether separate note from the point I’m making: this lack of access is seen as an obstacle to overcome, and other means of access will be tried if available.
It’s a different mental model than a first party solution to “ignore” files.
Weirdly, the existing first party solutions around denying commands don't seem to help here.
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.
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.
> 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!
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.
That is not a fault that's specific to engineers. Lots of smart lawyers think they can learn basically anything over a weekend of hard study. It's probably a blind spot of intelligent people.
> Just like engineers thought all sales did was bother people, and all marketing did was send emails
i mean, sure, the marketing one may be a bit simplified as the emails also need to have pretty pictures in them. and yeah, sure, sales people do need to find the people they’ll eventually start bothering later.
/s
> But all our CTOs seems to have collectively thrown us to the wolves.
the kind of person who usually finds their way into the executive class doesn’t get there by looking after those under them. they get there by avoiding blame and taking credit.
which, funnily enough, is exactly what a hype cycle is all about.
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 knowledge gap is very real. Because unsavvy users are just going to paste the API key into codex and say "make it work". For the truly lazy/uninformed, codex has computer use, and are going to tell it go into Vercel/Netlify/Stripe/Cloudflare for them, and get the API key, and save it to .env for them. So users knowing they need such a feature in the first place should be celebrated when the alternative is even dumber.
huh, but what if the AI trashes my git repo? maybe it just deletes the .git folder entirely. a deterministic undo wouldn’t be the silliest feature, for the current definition of “AI”.
The answer is the same: You give it either read-only or its own copy separate from the one you care about.
The requested feature wouldn't be a robust solution here either for the same reasons.
Besides, have you noticed the amount of other amateur-hour bugs anf jank in Codex going for weeks or months without proper resolution? Given that, why would you want and trust their solution here over alternatives, specifically?
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.
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.
> Does that work? I've never seen it used. It seems easy to escape.
Yes, it does work for its intended purpose. It has often been used in combination with chroot[0] as well.
> 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.
These approaches are not mutually exclusive with restricted shell use. For example, one could use FreeBSD jails to secure Apache httpd and/or Nginx and still employ a restricted shell to evaluate requests.
I'm seeing a ton of restricted mode escapes documented online, like https://0xffsec.com/handbook/shells/restricted-shells/ so I'm not so sure. When basic utilities like less, man, and awk can run subshells it's quite a mess.
Bash restricted mode needing a chroot may suggest that Claude also needs a chroot (or restricted file permissions, jail, etc).
> Bash restricted mode needing a chroot may suggest that Claude also needs a chroot (or restricted file permissions, jail, etc).
I believe running coding agents within a jail/container is a "best practice" to limit their blast radius. At least, this is what people I respect have conveyed to me.
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.
You could also produce special purpose applications this way, say to provide access to the online library catalog, or a run a gopher client for use in a public terminal lab. Telnetting to a unix account running some sort of restricted shell was how these often worked.
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.
.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.
> 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.
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.
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.
It's not that I don't understand, it's that I don't care. Normies routinely hurt themselves trying to do professional work. We don't blame the tools when that happens, we blame the normies.
It’s been five years since they changed their license. Today’s layoffs cannot be blamed on AWS and GCP. It’s been years and they have differentiated products now.
I’ve had my civic coupe valeted at hotels and wasn’t doing staying anywhere special. Business trip where I drove the 100 miles to Baltimore and stayed at the hotel my company put me up in. Also, I’ve had medical appointments places where they valeted your car for free.
I feel like having your car valeted was something special when I was a kid, but now it doesn’t really take something special.
They basically said "Deepseek ran 150,000 requests and here's the gist of one of their prompts". Anthropic doesn't know which accounts are Deepseek proxies beforehand, so definitely sounds like retrospective analysis of broad user logs to me.
Of course Anthropic realizes saying this straight is problematic so they said they examined request metadata, but no, I don't think they can get this kind of insight from metadata (token counts, request time, etc.)
I’m sorry, but the DMA is mandating Cambridge Analytica-type access to data. That whole scandal was people on Facebook granting a third party access to all the data they had access to. And Cambridge Analytica lied about how they were going to use it.
Facebook got roasted for this, but now the EU wants the same open data policy from every big tech company.
Oh wow... Cambridge Analitica had access to all the data Facebook had on you without you knowing it and without you knowing the extent of the data Facebook had on you. EU wants you to be able to knowingly install apps on your phone and give them access to the data on your phone you chose to.
reply