AI Coding Agents: Between Two Uncomfortable Choices

AI Coding Agents: Between Two Uncomfortable Choices

When AI coding agents first arrived, many of us faced a dilemma that felt impossible. We could give them free rein over our data and systems, putting both at risk, but letting them do great things unattended. Or we could use them cautiously and watch others, who accepted more risk by temperament (you can call it bravery, you can call it ignorance, and probably both would be right), move faster. Either way, many of us were caught between a rock and a hard place.

For months I waited for a solution to come, either from the open-source community or directly from the frontier labs: some sandbox (a term that is overused today, but that’s a discussion for another time) that offered reasonable security while also being easy to use. Well, many sandboxes were indeed released, but almost all of them targeted production use cases, i.e. programmable agents built on SDKs. From hosted services like E2B to open-source projects like microsandbox, that part of the industry matured and gained popularity quickly.

The more I tried using those sandboxes, however, the more I realized they tend to get in the way of the AI coding agents (e.g. Claude Code, Codex) most of us run daily in our terminals. They were good solutions, but not for my problem. As a result, I—and frankly, most of us—kept running those coding agents directly on our machines, or on clunky VMs, or on separate VPSs or spare Mac Minis… You get the gist.

Then came nono.sh, a product well suited to terminal coding agents, and one I think is promising for many reasons (it deserves an essay of its own, as it has many good characteristics other sandboxes lack). It is a process-level sandbox, so the agent still shares the host kernel: on Linux it relies on Landlock, and on macOS on Seatbelt. Landlock has seen full sandbox escapes (e.g. CVE-2024-42318), and Seatbelt has had its own share (e.g. CVE-2022-26706). A few CVEs do not make those primitives less secure by any strict definition, though. That would be a very naive conclusion to draw. After all, as we will shortly see, microVM sandboxes are not immune to escapes either. Still, I won’t hide that the opacity of Apple’s Seatbelt and the lack of microVM sandboxes left me with an itch that even the promising nono could not scratch on macOS, although, in my eyes, it is one of the most interesting candidates so far.

And then came Docker Sandboxes, a microVM-based tool that is very similar to SideKernel: better in many ways (it has a very interesting TUI, secret management features, and a very nice way to manage block and allow lists for external network access), worse in some (it is not open source and lacks many features I wanted). And just this month, September 2026, Docker Sandboxes had its own sandbox escape through symlinks (CVE-2026-77179). While developing SideKernel, I found and fixed similar symlink escapes myself. So there is no such thing as perfect security. But using a sandbox is almost certainly a better idea than not using one. I could cite a source for this claim, but I suspect you already believe me.

Last but not least, around the same time Apple itself released an interesting product: Apple Containers. And it was at this point that naming things in the sandboxing industry got really confusing.

Don’t be fooled by appearances: Apple Containers are not actually containers; they are microVMs. And Docker Sandboxes are microVMs too—which is baffling if you consider that the word ‘Docker’ has been synonymous with ‘containers’ for over a decade. Anyway, back to our discussion: Apple Containers are very similar to SideKernel in many ways. Both use the Kata kernel, and both rely on Apple’s Virtualization framework. However, Apple Containers is a runtime whose primary goal is workload orchestration, and it still lacked the ease of use and nativeness I was looking for in a sandbox. For a brief moment, I flirted with the idea of building SideKernel on top of it, but then I realized I would have inherited a lot of ‘bloat’ I did not need. I would also have lost the chance to learn so much about low-level programming and security.

So when the time came for my capstone project in Georgia Tech’s MSc in Cybersecurity, I decided to build the sandbox I had been dreaming of. One that is easy to use and does not have a confusing name. It was also, anecdotally, the sandbox others around me said they wanted: a sandbox that is reasonably secure, but out of the way. Up to that point, the only serious open-source candidate was nono. But I was curious to see how far microVMs could be pushed. So I started building SideKernel, figuring out along the way how to make developers actually want to use it.

Can a microVM feel almost invisible to the terminal user? Transparent. Native. Frictionless! The ambition is big, but so, it seems, are the obstacles.

The more I worked on it, the more I realized it was much harder than I had initially imagined. To be completely honest, I am not even convinced yet that microVMs are the right choice among the many isolation primitives our industry has for sandboxing, including Landlock/Seatbelt, language runtimes, userland kernels such as gVisor, and more. What I am sure about is that it is a road worth exploring, and instinctively I think it will bring value to our industry. But we have to walk it first, with humility and no grand claims, so that we aren’t quickly humbled by the grander reality of things.

Usability is a UX problem. But usability is also a security problem. And when it comes to sandboxes, it is underexplored (or, dare I say, not explored at all). If something is hard to use, people won’t use it. So what matters is building something that is not only reasonably secure but also reasonably easy to use. SideKernel is my attempt at that.

In practice, it looks like this. You open a terminal in a project folder of your choice and type sclaude instead of claude (or sk for a plain shell inside the sandbox). Claude Code launches inside its own microVM, and the current directory gets mounted, so edits flow both ways, just as if it ran on your Mac. The Claude authentication, skills and plugins come along automatically from the host. Copy and paste works as expected, text and images included (something that, comically, no other microVM sandbox has gotten right, to the best of my knowledge). Ports opened in the sandbox are forwarded to your host automatically. And if you want the agent cut off from the internet, sk-net off blocks all outbound traffic (while Claude keeps working). Anything else from your Mac gets in only with your explicit approval.

It is important to note, though, that SideKernel is still a research prototype, the result of my Georgia Tech practicum, not a mature product proven by time, extensive security testing or formal verification. Every step towards making it feel native (sharing files or the clipboard, reaching localhost, bringing host tools along) means more code, and every new feature grows the attack surface. Security is both tied to usability and at odds with it. I have already found and fixed several escapes during development, and I am almost certain there are more I haven’t found yet. If you come across one, please reported it privately on GitHub. I will look into every report and fix what I can, though as the only maintainer for now, it may take me a little while.

On the bright side, I hope you enjoy using SideKernel as much as I have enjoyed building and using it these past months. Experiment with it, contribute if you like, and compare it with other products. Just don’t let yourself believe that it is some inescapable fortress, because there ain’t one. Cybersecurity, after all, is risk management, not risk elimination. And I hope SideKernel helps you manage a bit more of that risk in your day-to-day development.

P.S. While writing this essay, I learnt about another notable sandbox recently released by NVIDIA: OpenShell.