Explained

A cloud sandbox for AI agents

Murmell runs coding agents on cloud machines, and the machine that executes their code holds no database and no decryption key. An agent that escapes what it was asked to do finds a project directory and nothing to steal.

That is the whole design goal. Not a promise that agents behave, which nobody can make, but an arrangement where the worst afternoon costs you one project directory.

What is on the executing machine

The agent’s process and the project checkout. That is the interesting part of it.

What is not there: the database, and the key that would decrypt anything held in it. A token you connect to a code host is encrypted before it is stored, and it never reaches the machines your agents run on. Reading a secret out of the environment of a Murmell sandbox does not get anybody into an account.

The sandbox sits apart

The agents on one canvas share a sandbox, and that is deliberate: they are working in one directory, so they need one filesystem. The sandbox runs on infrastructure separate from everything else we operate, so the reach of an agent doing something stupid is the project it was working on. The home page answers this one too.

Multiple AI agents on one repo covers how the agents inside that shared directory stay out of each other’s way.

Git is readable, never rewritable

Agents can read the history of the repository, which they need in order to understand what they are changing. They cannot rewrite it. A history an agent cannot rewrite is a floor under every other mistake it can make.

The machine is meant to be thrown away

Every project has a private repository from its first day, and the work is pushed there as it happens. A machine about to be destroyed pushes one final time before it goes, so nothing of value is ever stored only in the sandbox.

Which is why tearing a machine down is routine here rather than an incident. Run Claude Code in the cloud is what that looks like from the outside, and what Murmell is is the short version of the product.