We go live on Product Hunt on Tuesday. Before then, I'd love a few people to put the https://kosa8.com/ through its paces:
Post your rough edges, confusing docs or "why doesn't it do X" here. I'll fix what I can before launch and credit you in the changelog. I'll also be here all day on the 20th for questions.
Deleted the wrong folder? Force-pushed to main? Burned $200 of API credits in a loop? Read your .env?
We're collecting real stories (anonymous is fine) as we build kosa8. They shape which guardrails we build first. I'll reply to each one with how we'd stop it, or admit that we can't yet.
Mine: an agent "cleaned up" a node_modules folder... in the wrong directory.
Every MCP server you add is code running with your permissions: your files, your network, your tokens. Most of us install them from a README and a star count.
Do you read the source? Pin versions? Run them in a container?
Our take: containers share the host kernel, so for untrusted code a microVM is the safer wall, and kosa8's boot in about 0.5s, so speed isn't the trade-off it used to be.
The counterargument: gVisor and seccomp profiles go a long way, and VMs add complexity.
When you compare two prompts, two models or two agent configs, the result is only as fair as the starting environment. If attempt A ran on a machine that attempt B had already touched (a warm cache, a half-applied migration, a leftover temp file), you're measuring the mess, not the agent.
What we do: build one base sandbox with the project and its dependencies ready, take a snapshot, and fork it so every variant starts from exactly the same running machine. Then each variant runs, gets scored, and the losers are thrown away. kosa8 can fork a live sandbox into several independent copies (about half a second per clone on an Apple M-series Mac in our benchmark harness).
While building kosa8 we kept coming back to the same short list of controls that make it reasonable to let Claude Code, Codex or Cursor run without someone watching every command:
One VM per agent, not a shared container. Containers share the host kernel; code an LLM wrote a minute ago is untrusted by definition.
Network closed by default. Allow-list the model API and your package registries, enforced outside the VM so root inside can't lift it.
No long-lived credentials in reach. If ~/.aws or a .env is mounted, the agent has it.
Undo for the whole machine. Checkpoint before the risky step and rewind afterwards, processes and all.
Sandbox the tools too. Every MCP server is code running with your permissions.
A log you can verify. What did the agent actually run, and can you prove nobody edited the record?
Which of these do you actually do today, and what would you add? Honest answers welcome, including "none of them".
Hey everyone, I'm Drew, building kosa8. We launch here on Tuesday 20 October.
The question behind it: AI coding agents now run with your keys, your data and a shell. Most of us either babysit them or give them less to do than they could handle, because one wrong command or one poisoned web page is all it takes.
Kosa8 lets you run AI agents inside secure, isolated virtual machines without risking your own computer. Give Claude Code, Codex, or other agents their own sandbox, restrict what they can access, and checkpoint the entire running environment before risky changes. If something breaks, rewind in about a second — even running processes are restored. You can also fork environments to test multiple approaches in parallel, run local AI models, and manage everything from one dashboard.
