After using gpt5-codex inside codex-cli to produce this fork of DOSBox (https://github.com/pmarreck/dosbox-staging-ANSI-server) that adds a little telnet server that allows me to screen-scrape VGA textmode data and issue virtual keystrokes (so, full roundtrip scripting, which I ended up needing for a side project to solve a Y2K+25 bug in a DOS app still in production use... yes, these still exist!) via 4000+ lines of C++ (I took exactly one class in C++), and it passes all tests and is non-blocking, I was able to turn around and (within the very same session!) have it help me price it to the client with full justification as well as a history of previous attempts to solve the problem (all of which took my billable time, of course), and since it had the full work history both in Git as well as in its conversation history, it was able to help me generate a killer invoice.
So (if all goes well) I may be getting $20k out of this one, thanks to its help.
Does the C++ code it made pass the muster of an experienced C++ dev? Probably not (would be happy to accept criticisms, lol, although I think I need to dress up the PR a bit more first), but it does satisfy the conditions of 1) builds, 2) passes all its own tests as well as DOSBox's, 3) is nonblocking (commands to it enter a queue and are processed one set of instructions at a time per tick), 4) works as well as I need it to for the main project. This still leaves it suitable for one-off tasks, of which there is a ton of need for.
This is a superpower in the right hands.
I’ve been using Claude code since launch, must have used it for 1000 hours or more by now, and it’s never done anything I didn’t want it to do.
Why would I run it in a sandbox? It writes code for me and occasionally runs a build and tests.
I’m not sure why you’re so fixated on the “danger”, when you use these things all the time you end up realizing that the safety aspect is really nowhere near as bad as the “AI doomers” seem to make out.
You (and many, many others) likely won't take this threat seriously until adversarial attacks become common. Right now, outside of security researcher proof of concepts, they're still vanishingly rare.
You ask why I'm obsessed with the danger? That's because I've been tracking prompt injection - and our total failure to find a robust solution for it - for three years now. I coined the name for it!
The only robust solution for it that I trust is effective sandboxing.
I share your worries on this topic.
I saw you experiment a lot with python. Do you have a python-focused sandboxed devcontainer setup for Claude Code / Codex you want to share? Or even a full stack setup?
Claude's devcontainer setup (https://github.com/anthropics/claude-code/tree/main/.devcont...) is focused on JS with npm.
I wrote a bit about that in a new post this morning, but I'm still looking for an ideal solution: https://simonwillison.net/2025/Sep/30/designing-agentic-loop...
-create a separate linux user, put it in an 'appshare' group, set its umask to 002 (default rwxrwxr.x)
-optional: setup some symlinks from its home dir to mine such as various ~/.config/... so it can use my installed packages and opencode config, etc. I have the option to give it limited write access with chgrp to appshare and chmod g+w (e.g. julia's cache)
-optional: setup firewall rules
-if it only needs read-only access to my git history it can work in a git worktree. I can then make git commits with my user account from the worktree. Or I can chgrp/chown my main working copy. Otherwise it needs a separate checkout
I actually preferred running stuff in containers to keep my personal system clean anyway so I like this better than letting claude use my laptop. I'm working on hosting devcontainer claude code in kubernetes too so I dont need my laptop at all.
https://gitlab.com/txlab/ai/sandcastle/
Check it out if you're experimental - but probably better in a few weeks when it's more stable.
I feel this is overly exagerated here.
There is more issues that are currently getting leverage to hack with vscode extension than AI prompt injection, that require a VERY VERY complex chain of attack to get some leaks.
But that's a very big if. I've seen Claude Code attempt to debug a JavaScript issue by running curl against the jsdelivr URL for a dependency it's using. A supply chain attack against NPM (and those aren't exactly rare these days) could add comments to code like that which could trigger attacks.
Ever run Claude Code in a folder that has a downloaded PDF from somewhere? There are a ton of tricks for hiding invisible malicious instructions in PDFs.
I run Claude Code and Codex CLI in YOLO mode sometimes despite this risk because I'm basically crossing my fingers that a malicious attack won't slip in, but I know that's a bad idea and that at some point in the future these attacks will be common enough for the risk to no longer be worth it.
Again you likely use vscode. Are you checking each extension you download? There is already a lot of reported attacks using vscode.
A lot of noise over MCP or tools hypothetical attacks. The attack surface is very narrow, vs what we already run before reaching Claude Code.
Yes Claude Code use curl and I find it quite annoying we can't shut the internal tools to replace them with MCP's that have filters, for better logging & ability to proxy/block action with more in depth analysis.
Maybe it will never happen? I find that extremely unlikely though. I think the reason it hasn't happened yet is that widespread use of agentic coding tools only really took off this year (Claude Code was born in February).
I expect there's going to be a nasty shock to the programming community at some point once bad actors figure out how easy it is to steal important credentials by seeding different sources with well crafted malicious attacks.
Lots of ways his could happen. To name two: Third-party software dependencies, HTTP requests for documentation (if your agent queries the Internet for information).
If you don't believe me, setup a MITM proxy to watch network requests and ask your AI agent to implement PASETO in your favorite programming language, and see if it queries https://github.com/paseto-standard/paseto-spec at all.
More seen as buzz article about how it could happen. This is very complicated to exploit vs classic supply chains and very narrow!
????
What does "This" refer to in your first sentence?
The researcher has gotten actual shells on oai machines before via prompt injection
Nice job for coining the name for something but it’s irrelevant here.
How is someone going to prompt inject my local code repo? I’m not scraping random websites to generate code.
This sort of baseless fear mongering doesn’t help the wider ai community.
See comment here for more: https://www.hackerneue.com/item?id=45427324
You may think you're not going to be exposed to malicious instructions, but there are so many ways bad instructions might make it into your context.
The fact that you're aware of this is the thing that helps keep you safe!
Just yesterday my cursor agent made some changes to a live kubernetes cluster even over my specific instruction not to. I gave it kubectl to analyze and find the issues with a large Prometheud + AlertManager configuration, then switched windows to work on something else.
When I was back the MF was patching live resources to try and diagnose the issue.
In my own career, when I was a junior, I fucked up a prod database... which is why we generally don't give junior/associate people to much access to critical infra. Junior Engineers aren't "dangerous" but we just don't give them too much access/authority too soon.
Claude Code is actually way smarter than a junior engineer in my experience, but I wouldn't give it direct access to a prod database or servers, it's not needed.
My way of explaining that to people is to say that it's dangerous to do things like that.
If it is not dangerous to give them this access, why not grant it?
(Having said that, I'm just a kibitzer.)
I have a cursor rule stating it should never make changes to clusters, and I have explicitly told it not to do anything behind my back.
I don't know what happened in the meantime, maybe it blew up its own context and "forgot" the basic rules, but when I got back it was running `kubectl patch` to try some changes and see if it works. Basically what a human - with the proper knowledge - would do.
Thing is: it worked. The MF found the templating issue that was breaking my Alertmanager by patching and comparing the logs. All by itself, however by going over an explicit rule I had given it a couple times.
So to summarize: it's useful as hell, but it's also dangerous as hell.
Problem is: I also force it to run `kubectl --context somecontext`, as to avoid it using `kubectl config use-context` and pull a hug on me (if it switches the context and I miss it, I might then run commands against the wrong cluster by mistake). I have 60+ clusters so that's a major problem.
Then I'd need a way to allowlist `kubectl get --context`, `kubectl logs --context` and so on. A bit more painful, but hopefully a lot safer.
And yes, these are all "skill issues" - as in, if they had known better this wouldn't have happened to them, however I think it's fair to call these possibilities out to counter balance the AI is amazing and everyone should use it for everything type narratives as to instil at least a little caution.
I too use it extensively. But they’re very, very capable models, and the command line contains a bunch of ways to exfiltrate data off your system if it wants to.
Yes, it was a legit safety issue and worth being aware of, but it’s not it was a general case. Red teamers worked hard to produce that result.
This is nowhere near the contortions red teams sometimes go through. They noted in general that overly emphasizing initiative was taken ... seriously.
I use Sonnet and Opus all the time through claude. But I don't generally use them with dangerously-skip-permissions on my main laptop.
Was it a paper or something? Would you happen to remember the reference?
i.e. quite dangerous, but people do it anyway
You know what neighbors of serial killers say to the news cameras right?
"He was always so quiet and polite. Never caused any issues"
Also, I think shellagent sounds cooler.
I expect the portion of Claude Code users who have a dedicated user setup like this is pretty tiny!
Not the exact setup, but also pretty solid.
Instead I run it in bubblewrap sandbox: https://blog.gpkb.org/posts/ai-agent-sandbox/
As long as the supply chain is safe and the data it accesses does not generate some kind of jail break.
It does read instructions from files on the file system, I pretty sure it's not complex to have it poison its prompt and make it suggest to build a program infected with malicious intent. It's just one copy pasta away from a prompt suggestion found on the internet.
[0]: https://ricardoanderegg.com/posts/control-shell-permissions-...
- something general-purpose (not specific to LLMS (I myself don't use agents--just duck.ai when I want to ask an LLM a question)) - something focused on sandboxing (bells and whistles like git and nix integration sound like things I'd want to use orthogonal tools for)
I have no way of really guaranteeing that it will do exactly what it proposed and nothing more, but so far I haven't seen it deviate from a command I approved.
I've used it to troubleshoot some issues on my linux install, but it's also why the folder sandbox gives me zero confidence that it can't still brick my machine. It will happily run system wide commands like package managers, install and uninstall services, it even deleted my whole .config folder for pulseaudio.
Of course I let it do all these things, briefly inspecting each command, but hopefully everyone is aware that there is no real sandbox if you are running claude code in your terminal. It only blocks some of the tool usages it has, but as soon as it's using bash it can do whatever it wants.
Note that there needs to be open source libraries and toolings. It can’t do a Dolby Atmos master, for example. So you still need a DAW.
I would like a friendlier interface than the terminal, though. It looks like the “Imagine with Claude” experiment they announced today is a step in that direction. I’m sure many other companies are working on similar products.
Also, another important factor (as in everything) is to do things in many small steps, instead of giving one big complicated prompt.
The gap between coding agents in your terminal and computer agents that work on your entire operating system is just too narrow and will be crossed over quick.
Clearly not. Just put an LLM into some basic scaffolding and you get an agent. And as capabilities of those AI agents grow, so would the degree of autonomy people tend to give them.
That is still very much the case; the danger comes from what you do from the text that is generated.
Put a developer in a meeting room and no computer access, no internet etc; and let him scream instructions through the window. If he screams "delete prod DB", what do you do ? If you end up having to restore a backup that's on you, but the dude inherently didn't do anything remotely dangerous.
The problem is that the scaffolding people put around LLM is very weak, the equivalent of saying "just do to everything the dude is telling, no question asked, no double check in between, no logging, no backups". There's a reason our industry has development policies, 4 eyes principles, ISO/SOC standards. There already are ways to massively improve the safety of code agents; just put Claude code in a BSD jail and you already have a much safer environment than what 99% of people are doing, this is not that tedious to make. Other safer execution environments (command whitelisting, arguments judging, ...) will be developed soon enough.
But are all humans in jails? No, the practical reason being that it limits their usefulness. Humans like it better when other humans are useful.
The same holds for AI agents. The ship has sailed: no one is going to put every single AI agent in jail.
The "inherent safety" of LLMs comes only from their limited capabilities. They aren't good enough yet to fail in truly exciting ways.
LLM are in jail: an LLM outputting {"type": "function", "function": {"name": "execute_bash", "parameters": {"command": "sudo rm -rf /"}}} isn't unsafe. The unsafe part is the scaffolding around the LLM that will fuckup your entire filesystem. And my whole point is that there are ways to make that scaffolding safe. There is a reason why we have permissions on a filesystem, why we have read only databases etc etc.
For scaffolding to be "safe", you basically need that scaffolding to know exactly what the LLM is being used for, and outsmart it at every turn if it misbehaves. That's impractical-to-impossible. There are tasks that need access for legitimate reasons - like human tasks that need hammer access - and the same access can always be used for illegitimate reasons.
It's like trying to engineer a hammer that can't be used to bludgeon someone to death. Good fucking luck.
Excellent article in this vein: https://jxnl.co/writing/2025/09/04/context-engineering-rapid...
One criticism on current generation of AI is that they have no real world experience. Well, they have enormous amount of digital world experience. That, actually, has more economical value.
I suppose they’re dangerous in the same way any terminal shell is dangerous, but it seems a bit of a moral panic. All tools can be dangerous if misused.
Even with approvals humans will fall victim to dialog fatigue, where they'll click approve on everything without reading it too closely.
What are we even talking about? I think life itself grants us the right to get high or pet wild animals or swim the atlantic or sudo rm-rf... Or yes-and-accept-edits at 3AM with a 50 hour uptime (yes guilty) but then we don't get to complain that it's dangerous. We surely were warned.
Maybe something like bubblewrap could help
They still don't have good integration with the web browser, if you are debugging frontend you need to carry screenshots manually, it cannot inspect the DOM, run snippets of code in the console, etc.
I've seen Codex CLI install Playwright Python when I asked it to do this and it found it wasn't yet available in the environment.
It's pretty new, but so far it's been a lifesaver.
https://news.ycombinator.com/newsguidelines.html
Edit: We've had to ask you this more than once before, and you've continued to do it repeatedly (e.g. https://www.hackerneue.com/item?id=45389115, https://www.hackerneue.com/item?id=45282435). If you don't fix this, we're going to end up banning you, so it would be good if you'd please review the site guidelines and stick to them from now on.
I was under the impression that Docker container escapes are actually very rare. How high do you rate the chance of a prompt injection attack against Claude running in a docker container on macOS managing to break out of that container?
(Actually hang on, you called me out for suggesting containers like Docker are safe but that's not what I said - I said "a safe container" - which is a perfectly responsible statement to make: if you know how to run them in a "safe container" you should do so. Firecracker or any container not running on your own hardware would count there.)
That's the secret, cap... you can't. And it's due to in band signalling, something I've mentioned on numerous occasions. People should entertain the idea that we're going to have to reeducated people about what is and isn't possible because the AI world has been playing make believe so much they can't see the fundamental problems to which there is no solution.
True but all it will take is one report of something bad/dangerous actually happening and everyone will suddenly get extremely paranoid and start using correct security practices. Most of the "evidence" of AI misalignment seems more like bad prompt design or misunderstanding of how to use tools correctly.
Claude Code, Codex CLI etc can effectively do anything that a human could do by typing commands into a computer.
They're incredibly dangerous to use if you don't know how to isolate them in a safe container but wow the stuff you can do with them is fascinating.