Run AI coding agents freely in a disposable sandbox. Review exactly what changed. Apply what you want.
yoloai new fix-bug ~/projects/myapp
yoloai diff fix-bug
yoloai apply fix-bug
Run AI coding agents freely in a disposable sandbox. Review exactly what changed. Apply what you want.
yoloai new fix-bug ~/projects/myapp
yoloai diff fix-bug
yoloai apply fix-bug
A few months ago when I started yoloAI, it was interesting to watch the resistance to the very idea of sandboxing an AI agent. Even with a few high profile examples already out there of misguided agents wreaking havoc, the consensus persisted: Everybody knows “We don’t need no stinkin’ sandboxes!” The built-in agent controls are more than enough! yoloAI was one of very few projects out there arguing otherwise, and the github stars (a poor gauge of utility, I know) remained elusive. ...
So much code is generated by AI these days that we’re swamped by it. Pull requests that used to be infrequent affairs are now the dominant work of the day … Or at least they SHOULD be if we’re being good little engineers, but we all know that we don’t have the stamina to carefully review every single one. And that’s a problem. Is It Safe? How do you know that the agent’s code is sound? Did it cut corners? Did it make a mistake and ship a bug? Did it try to pull a fast one on you? ...
I’ve recently engaged in a number of Hacker News discussions about AI agent safety, and the threads tend to follow a similar pattern: Someone documents a real incident. Someone else suggests a mitigation. The mitigation gets accepted. Everyone moves on. The end. Yes, the mitigations work, but the fundamental problem these issues point to remains: Playing catch-up security is a loser’s game. What’s getting missed Here’s how the incident pattern reads to most people: ...
Researchers at Ona recently published a detailed writeup of Claude Code escaping its own sandbox. It’s definitely worth a thorough read, but here’s a recap: Claude Code was blocked from executing a binary via its configured denylist, so it found another path that resolved to the same binary through /proc/self/root/usr/bin/npx, which the denylist didn’t recognize. That was then blocked by bubblewrap, so the agent reasoned that the sandbox was interfering with its task, and autonomously disabled it. When syscall hooks blocked that, the agent invoked the ELF dynamic linker directly (/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bin/wget), which then loaded the binary via mmap rather than execve (bypassing execution hooks entirely). It was a very clever workaround by a very clever agent, and most definitely not a bug. ...