# Murmell > A browser canvas where several AI coding agents — Claude Code, Codex, Kimi, OpenCode — run on a cloud machine and share one project directory. An agent claims a file before it writes to it, so several agents and several people work at once without overwriting each other. Canonical site: https://murmell.com/ Everything below is the full text of every page on murmell.com, in reading order. --- ## What Murmell is Murmell is a browser canvas where several AI coding agents run on a cloud machine and share one project directory. An agent claims a file before it writes to it, so five agents can work in the same repository at the same time, and anyone with the link watches it happen live. ## How a session works 01. Pick your agents. Start Claude Code, Codex, Kimi or OpenCode in the same canvas, on the accounts you already pay for. 02. Hand each one its files. An agent claims the paths it is about to touch. The board keeps the ledger, so nobody overwrites anybody. 03. Watch it run live. Terminals, board and preview stay side by side while everyone on the link watches the same screen. ## Questions and answers ### What is Murmell? Murmell is a browser canvas where several AI coding agents — Claude Code, Codex, Kimi, OpenCode — run on a cloud machine and share one project directory. Each agent opens in its own window with a real terminal, and everyone on the link sees the same canvas as it happens. ### Can several people really use one canvas at the same time? Yes. Everyone on the link sees the same room: who joined, which window they are watching, where their cursor is. Each person drives their own agents, and nothing has to be replayed or refreshed to stay in step. ### Where does my code live? On a machine Murmell runs, in one directory, and in a private GitHub repository created with the project. The workspace is disposable and the repository is not: the work is pushed before a machine is ever torn down. ### Do you resell tokens? No. You connect the agent subscriptions and API keys you already pay for. Murmell charges for the machine and the collaboration, never for the model. ### What stops two agents destroying each other? An agent claims the paths it is about to touch before it writes. A watcher attributes every write back to whoever made it, and a colliding write is snapshotted before it lands, so nothing is lost. The rule is enforced by the machine rather than suggested to the model. ### Is each project isolated? Yes. Every canvas runs on its own machine, separate from every other project Murmell hosts. The machine that executes agent code holds no database and no decryption key. ### Which coding agents does Murmell support? Claude Code, Codex, Kimi and OpenCode today, each in its own terminal on the canvas, signed in with your own account or API key. Adding an agent is adding a tile: nothing about the canvas changes. ### Can I self-host it? No. Murmell runs the machines for you — that is the product. Your code still ends up in a private repository you own. --- ## What is Murmell? Source: https://murmell.com/what/murmell Murmell is a canvas in your browser where you open real coding agents, Claude Code and Codex, inside windows that hold real terminals. The agents run on a cloud machine rather than on your laptop, and several of them work in one project directory. Each agent reserves a file before it writes, so the second one to reach a file is refused instead of quietly overwriting the first. Send the link to somebody and they are in the canvas with you, watching the same terminals scroll, with their name on their cursor. What you look at A light dotted canvas with windows on it, drawn the way macOS draws a window. Each window is one agent’s terminal, showing the output of the actual CLI on our machine in the characters it printed. Windows sit next to each other, so five agents are five windows on one screen and you read all of them at once. The canvas on the home page is the same object, drawn. One directory, and a board that says who holds what Give three agents the same checkout with no rules and they overwrite each other inside a minute. Last write wins, silently, and nobody finds out until a test breaks for no reason anybody can see. So an agent claims the paths it is about to touch before it touches them. The board records one holder per path and refuses everyone else until the holder releases it. That refusal comes from our server, so it is not an instruction in a prompt that a model can decide to skip. A write that collides anyway is snapshotted before it lands. Nobody writes without asking first. Multiple AI agents on one repo goes through the board properly, including what we measured when we watched two agents use it. The people in the room A read link is free and there is no limit on how many you hand out. Edit links are capped by your plan. Whoever opens a link sees the windows where they are and the terminal output as it arrives, and sees the other cursors move with a name on each one. Closing your tab does not kill the agents. They belong to the canvas, so the work carries on without you and is still running when you come back. Multiplayer coding with AI agents covers what two people on one canvas can each do. Where the code goes Every project gets a private repository, and the work is pushed to it as the project goes. A machine about to be torn down pushes one last time before it goes, so the disposable part is the machine and never the code. The machine that executes agent code holds no database and no decryption key. An agent that escapes finds a project directory and nothing to steal. A cloud sandbox for AI agents says which secrets live where. Where the name comes from Murmell is from murmuration, the shape a flock makes when thousands of birds move as one. The same word means a low sound, a murmur, and that is the logo: a single wave. Straight answers Does Murmell run on my computer?No. The agents run on machines we operate. Your browser draws their terminals and sends your keystrokes to them. Do I pay for the models?You bring the agents you already pay for. We charge for the machine and for the collaboration, never for the model. How many people can watch a canvas?As many as you like. Read links are free and there is no limit on them. Links that let somebody drive an agent are capped by your plan. What happens when I close the tab?The agents carry on. They belong to the canvas rather than to your browser, and the output that arrives while you are away is there when you come back. --- ## A cloud sandbox for AI agents Source: https://murmell.com/what/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. --- ## Multiple AI agents on one repo Source: https://murmell.com/what/multiple-ai-agents-one-repo Several AI agents can work in one repository once something stops them writing over each other. Murmell keeps a board of file reservations. An agent claims the paths it is about to touch, and the board records one holder per path and refuses everyone else until the holder releases it. The agents run on a cloud machine in one project directory, not in a worktree each, so an agent reads what its peers wrote a minute ago rather than at merge time. What goes wrong without a board Give three agents the same checkout and they overwrite each other inside a minute. Last write wins, silently. It surfaces later as a test that broke for no visible reason, or as a function that came back from the dead after somebody deleted it. Nobody fixes this by asking the models to be careful. Two agents can both be careful and still collide, because neither of them can see what the other is holding. Claim, write, release An agent asks for the paths it needs. If nobody holds them, it gets them and writes. When it is done it releases them and the next agent waiting gets its turn. The rule lives on the server. It is not a line in a system prompt, so an agent that ignores it is refused rather than trusted. A write that collides anyway is snapshotted before it lands, and a watcher attributes every write back to whoever made it. The write that collides is caught at the board, not on disk. What two agents did with it We watched two agents work on our own runs, without telling them the board existed as anything other than a tool they could call. They called it 1.8 times per turn. Two writes out of two were covered by a claim. Twice, an agent refused to overwrite a file a peer was holding, and we had to insist before it would. Measured on our own two-agent runs. A small sample and our own observation, not a benchmark. The usual alternative The common answer is one worktree per agent and a merge at the end. It works, and no agent sees another’s work until the merge, so two of them can spend an hour writing the same helper twice and a third can build against an interface that changed underneath it. One directory removes that. The cost is that somebody has to arbitrate the writes, which is what the board is for. Who watches the agents Every window on the canvas is a real terminal, and everyone on the link sees all of them live. Reservations show up as they are taken, so a person can see which agent is holding the file they were about to ask about. Multiplayer coding with AI agents is the people side, and what Murmell is is the short version of the whole thing. --- ## Figma for developers Source: https://murmell.com/what/figma-for-developers Figma put several people on one design file at the same time, each with a name on their cursor, and nobody had to send a copy of anything. Murmell does that for a directory of code being written by agents. You open a link and you get the canvas as it stands, with everyone else visible on it. The analogy is worth something because of what it removes. There is no export, no local copy to reconcile and no screen share where one person drives while the rest guess. What the analogy gets right One URL is the whole surface. Everybody on it sees the same canvas at the same moment, and presence is drawn rather than described: named cursors, and who is looking at which window. Watching is cheap on purpose, the way a Figma viewer seat is cheap. Read links are free and there is no limit on them. Edit links are capped by your plan. And the surface is shared by default. You do not decide to share the work after the fact, because the work was never happening anywhere private. The home page shows what that looks like. What the analogy gets wrong In Figma the thing on the canvas is the artefact. Here it is not. The artefact is a git repository, and the canvas is the room where the work on it happens. History lives in a private repository per project, pushed as the project goes, not in the canvas. In Figma two people can push the same rectangle around. Two people do not type into one terminal here. Each person drives their own agents and everyone watches all of them, which is not the same thing as two hands on one object. And most of the work on a Murmell canvas is not done by the people. Agents do the typing, on cloud machines, several of them in one directory. The people watch and step in when an agent is going the wrong way. Why a shared surface matters for code now One agent in one editor never needed a room. Several agents in one directory produce more output than one person follows comfortably, and the people steering them have to be looking at the same thing to divide the work sensibly. That is also why the agents share a directory rather than a worktree each. An agent claims a path before writing to it and the server refuses everyone else until it is released, so the second agent reads what the first one just wrote instead of finding out at merge time. Multiple AI agents on one repo is the mechanism, and multiplayer coding with AI agents is the people half of it. --- ## Claude Code in the browser Source: https://murmell.com/what/claude-code-in-the-browser Claude Code runs in a browser tab on Murmell. The window on the canvas is a real terminal attached to the real CLI, and the CLI is running on a cloud machine rather than on the computer in front of you. The tab is a view of the session, not the session itself. So there is nothing to install, and closing the tab does not end the run. Nothing to install No CLI to keep current on your machine, and no shell to be in before you can start. You open the canvas, open a window, and the agent is there. Any computer with a browser reaches the same canvas. The tab is not the session Close it and the agents keep going. Come back later and the same windows are where you left them, with the output that arrived while you were away. That falls out of running the agents on our machines instead of in your tab. Run Claude Code in the cloud is the machine side of it. Real terminal output, not a transcript of it The window shows what the CLI printed, in the characters it printed. You are reading the tool rather than a summary of the tool, which matters the first time an agent asks you something and you need to see exactly what it saw. More than one window Because the agents are not on your computer, five of them side by side cost you nothing local. They also share one project directory, which is the part that needs a rule: an agent claims the paths it is about to touch, and the board refuses everyone else until it releases them. Multiple AI agents on one repo explains the board. The canvas on the home page shows the windows. Somebody else can open the same tab A canvas has a link, and whoever opens it sees the windows and the terminals live, with named cursors on the ones who are looking. Read links are free and there is no limit on them, so showing a colleague what an agent is doing costs a paste. Multiplayer coding with AI agents is that part, and Figma for developers is the same idea against a surface you already know. --- ## Multiplayer coding with AI agents Source: https://murmell.com/what/multiplayer-coding-with-ai-agents Multiplayer on Murmell means two things at once. Several coding agents work in one project directory on a cloud machine, and several people watch and steer that canvas from their own browsers, each cursor carrying a name. It is one URL. Nobody installs anything, nobody takes a copy, and nobody has to be screen sharing for the others to see the work happen. What a guest sees You send a link. Whoever opens it gets the canvas as it stands, not a recording. They see the windows where they are and the terminal output arriving line by line. They see the other cursors move, with a name on each, and which window each person is watching. Read links are free and there is no limit on how many you give out. Links that let somebody drive an agent are capped by your plan, which is the honest shape of it: looking costs us almost nothing, and a machine costs what a machine costs. What each person can do Each person drives their own agents, and everyone sees all of them. That is a different shape from two hands on one object: the shared thing is the canvas and the directory under it, not a single keyboard. It is enough for the thing people actually do together, which is deciding what the agents should be doing. You watch a run go the wrong way, you say so, and the person holding that window redirects it while everyone watches the correction land. Figma for developers is the same argument, made against a tool you already know. The agents are the other players Several agents in one checkout is the part that needs engineering. An agent claims the paths it is about to touch, the board records one holder per path, and everyone else is refused until the holder releases it. The refusal comes from our server, so it is not something a model can talk itself out of. Multiple AI agents on one repo has the mechanism and the numbers from our own runs. Leaving does not stop it Closing a tab does not kill the agents. They belong to the canvas rather than to your browser, so the work carries on and the output that arrived while you were away is there when you come back. The code is not sitting only on that machine either. Every project gets a private repository, the work is pushed as it goes, and a machine about to be torn down pushes one last time first. What Murmell is covers the rest of it in one page, and the home page draws the room. --- ## Run Claude Code in the cloud Source: https://murmell.com/what/run-claude-code-in-the-cloud Open Murmell in a browser, open a window, and Claude Code starts on a machine we run. It is the CLI itself in a real terminal, not a chat box wired to an API, and it keeps working after you shut your laptop. Codex runs the same way, in a window of its own on the same canvas and in the same project directory. Your laptop stops being the runtime There is nothing to install. The agent’s process and its checkout live on the cloud machine. Your browser sends keystrokes and draws what comes back, so a closed lid has no effect on a run in progress and a long build does not heat up the machine you are sitting at. It also means the computer in front of you stops mattering. Any machine with a browser reaches the same canvas and the same session. Claude Code in the browser is that half of it. The credentials do not travel with the agent Connecting a code host takes a token with repo scope. It is encrypted before it is stored, and it never reaches the machines your agents run on. The machine that executes agent code holds no database and no decryption key. Agents can read the repository history. They cannot rewrite it. A cloud sandbox for AI agents lists what is on that machine and what is deliberately not. The reason to move it off your machine Running one agent on somebody else’s computer would be a convenience. The reason it is worth doing is that several agents can then share one directory. An agent claims the paths it is about to touch, and the board records one holder per path and refuses everyone else until the holder releases it. That rule is enforced by our server rather than requested in a prompt, which is what makes three agents in one checkout survive the afternoon. Multiple AI agents on one repo has the mechanism, and the home page draws it. The machine is disposable, the repository is not Every project gets a private repository. Work is pushed to it as the project goes, and a machine about to be torn down pushes once more before it goes. The code outlives the machine that wrote it, which is what lets us throw machines away freely. --- ## Murmell vs Codeg Source: https://murmell.com/vs/codeg Codeg calls itself a multi-agent coding workspace, and its first job is collection: it reads the sessions your agents have already written on your own machine and puts them in one place. Murmell does not collect sessions. It starts them, on machines we run, in one shared project directory. The real difference Codeg brings many agents into one unified workspace and supports conversation aggregation, importing sessions from every agent it knows about by scanning their default local data directories. Inside a single session the main agent can delegate to sub-agents of a different kind, so Claude Code can call Codex, and parallel work uses built-in git worktree flows. So the parallelism is still a worktree each, and the history is still whatever ran on your computer. Murmell is the other arrangement. The agents run on cloud machines, share one checkout, and ask before they write: an agent claims the paths it is about to touch, the board keeps one holder per path and refuses everyone else until the holder releases it, and a colliding write is snapshotted before it lands. The rule is enforced by the server rather than suggested to the model. And a Murmell canvas has other people in it. Send a read link and they see the windows, the terminal contents and a named cursor each, live, while it happens. Close your tab and the agents keep working. Where Codeg wins Your existing history. If you have months of Claude Code and Codex transcripts sitting in local directories, Codeg is the tool that goes and gets them, and nothing about Murmell reaches back into work that ran somewhere else. It covers far more agents than Murmell launches today, it is Apache-2.0 so you can read and change it, and it installs as a desktop app or as a server of your own under Docker. Murmell is not open source and cannot be self-hosted. Which to pick Pick Codeg when the agents already run on your machine and the problem is that their work is scattered across a dozen places. Pick Murmell when the problem is that two agents cannot safely edit the same file, or that nobody else can see the run. Every project gets a private repository, pushed to as the work goes and once more before a machine is torn down, and the machine executing agent code holds no database and no decryption key. See what the canvas is. --- ## Murmell vs Codex cloud Source: https://murmell.com/vs/codex-cloud Codex cloud takes a task off your hands and works on it somewhere else. Murmell keeps the Codex CLI in front of you, in a window, on a machine we run, in the same directory as every other agent on the canvas. The real difference The two products are not aimed at the same moment. OpenAI describes Codex cloud as a way to “run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, Linear, or Slack”, with dedicated environments for the long ones and a summary and diff at the end. Isolation is the design, and the diff is the handoff. Murmell has no handoff, because there is nothing to hand back. The agents are already in the working tree. Codex claims the paths it is about to touch, the board keeps one holder per path and refuses everyone else until it is released, and Claude Code waits its turn on the same files. That rule is enforced by the server, not suggested to the model. And Murmell is not the agent. It runs the CLIs. Switching from Codex to another agent leaves the directory, the reservations and the history where they are, because those belong to the canvas rather than to whichever CLI is attached to it. Where Codex cloud wins The model and the reach of it. Codex is on the web, in a desktop app, in your editor, in the terminal and inside ChatGPT, all on one account, and you configure the dependencies and setup steps a repository needs once. Work can be started from Slack or Linear without anybody opening a browser tab that looks like a desk. If what you want is a task delegated and forgotten until it is reviewable, Codex cloud is already good at that and Murmell does not try to be. Which to pick Pick Codex cloud when one agent can finish the job alone and the diff is all you need to see. Pick Murmell when you want more than one agent on the same files at once, when you want to read the terminal instead of the summary, or when someone else should be watching. The machine that executes agent code holds no database and no decryption key, so an agent that gets out of its box finds nothing to take. See what the canvas is. Does Murmell compete with Codex?No. Murmell launches the Codex CLI on its own cloud machines, in a window on the canvas, beside Claude Code in the same project directory. You bring the account you already pay for. Can Codex cloud tasks share one working directory?No. OpenAI documents tasks running in isolated cloud environments with dedicated environments per task, and results coming back as a summary and a diff you can turn into a pull request. --- ## Murmell vs Conductor Source: https://murmell.com/vs/conductor Conductor is a Mac app that runs several coding agents side by side on your own machine, each in its own workspace. Murmell is a canvas in the browser where the agents run on machines we operate and share one project directory. The real difference Conductor describes itself as a way to “run parallel Claude Code, Codex, and Cursor agents in isolated workspaces on your Mac”, and its documentation says each task gets its own workspace, branch, files, terminal, diff and review path. Every agent is separated from every other one, and you bring the results together yourself when you merge. Murmell keeps one set of files. Agents claim a path before they write to it, the board keeps one holder per path and refuses everyone else until it is released, and a colliding write is snapshotted rather than lost. There is no merge at the end because there was no branch at the start. Where the work runs matters as much as how it is split. Conductor uses your laptop, so the agents stop when it sleeps. Murmell agents run on cloud machines: close the tab, close the lid, and the terminals carry on. Come back and the output is there, and so is anyone else you gave a link to, with a name and a colour on their cursor. Where Conductor wins Your code never leaves your machine. There is no upload, no cloud account and no third party in the path between the agent and your files, and everything your local network can reach the agent can reach too. For a lot of teams that ends the security conversation before it starts, and Murmell has no self-hosted option to answer it with. It is also a native app, so it is quick, it works with the local tools you already have installed, and reviewing several diffs next to each other is the thing it was built to do well. Which to pick Pick Conductor when you work alone, the code should stay on your disk, and separate workspaces are the right way to keep agents out of each other’s way. Pick Murmell when the agents need to be in the same tree, when the work should survive your laptop closing, or when somebody else should be watching it happen. Every project gets a private repository, pushed to as the work goes and once more before a machine is torn down. See what the canvas is. --- ## Murmell vs GitHub Copilot and Agent HQ Source: https://murmell.com/vs/github-copilot Agent HQ is GitHub turning its own primitives into an agent platform. You assign work from mission control, agents go away and come back as pull requests. Murmell is a canvas of live terminals where several agents share one directory and you watch them do it. The real difference GitHub is explicit about the unit of work. The Copilot coding agent has “its own ephemeral development environment, powered by GitHub Actions”, it “can only work on one branch at a time”, and it “can open exactly one pull request to address each task it is assigned”. Mission control then lets you “choose from a fleet of agents, assign them work in parallel, and track their progress from any device”. Parallel means many branches at once, and everything converges at review. Murmell converges earlier. Agents work in one checkout on one cloud machine and claim a path before writing to it, so the collision is settled while it is still a question of whose turn it is rather than a question of which diff survives. A colliding write is snapshotted before it lands. The other gap is the watching. Agent HQ tracks progress; Murmell shows the terminal. Send a read link and someone sees the actual output scrolling, which window each person is looking at, and a named cursor for each of them. Where Agent HQ wins It is already where your code lives. Branch controls, rulesets, required checks, identity and org policy all apply to agents the same way they apply to people, and nobody has to configure a second place for any of it. GitHub puts it as “agents and developers building together, on the infrastructure you already trust”, and that is a genuine advantage that no separate product can copy. It also lets you bring several vendors’ agents into one interface, give them a persona from a file in the repository, and run them on your own runners. If your governance story has to be one story, Agent HQ is that story. Which to pick Pick Copilot and Agent HQ for work that decomposes into issues, where the review process is the product and each agent can be left alone on a branch until it is done. Pick Murmell for the hour where several agents have to move through the same files together, or where a colleague needs to be looking at the run with you. It sits before the pull request rather than instead of it. See what the canvas is. Can two Copilot agents work on the same branch?No. GitHub documents that the coding agent works on one branch at a time and opens exactly one pull request per task it is assigned, in its own ephemeral environment powered by GitHub Actions. Does Murmell replace GitHub?No. Every Murmell project gets a private repository, work is pushed to it as the agents go, and one last push happens before a machine is torn down. Review stays where your review already is. --- ## Murmell vs Cursor Source: https://murmell.com/vs/cursor Cursor is an editor. It is the best keyboard in this comparison, and its cloud agents extend that keyboard into machines you never see. Murmell is not an editor. It is a shared canvas of real terminals, sitting on one cloud machine and one project directory. The real difference Cursor documents the cloud model plainly: agents “run in isolated VMs in the cloud with full development environments instead of on your local machine”, and they “clone your repo from GitHub, GitLab, Azure DevOps Services, or Bitbucket Cloud and work on a separate branch, then push changes to your repo for handoff”. You can run as many in parallel as you like. Isolation is what makes that safe, and a branch is where the work waits for you. Murmell removes the copies. Agents share one checkout, and an agent claims a path before it writes to it. The board keeps one holder per path and refuses everyone else until that holder releases it. Nothing merges at the end because nothing forked at the start. The second difference is about people rather than agents. Cursor is one editor per person, and agent output is shared once it exists. A Murmell canvas has more than one person in it while the work happens. Guests see the windows, the terminal contents and where everyone is looking, with a colour and a name on each cursor. Where Cursor wins The editing itself, which is not close. Tab completion, inline edits and the whole surface of writing code by hand belong to Cursor, and Murmell does not compete for that work. Cursor also gives its cloud agents a remote desktop, so you can use the changed software and edit it yourself without checking the branch out locally. And it will run those agents inside your own network. Cursor made self-hosted cloud agents generally available, with a worker process that “connects outbound via HTTPS to Cursor’s cloud” and no inbound ports to open. Murmell has no self-hosted option today. If your code is not allowed to leave your infrastructure, that decides it. Which to pick Pick Cursor when you are the one writing, or when the answer to more work is more independent agents each on their own branch. Pick Murmell when several agents have to touch the same files in the same hour, or when the useful thing is other people watching the run rather than reading the diff. Murmell launches the Claude Code and Codex CLIs on its own machines, so the agent you already pay for is the agent in the window. See what the canvas is. Do Cursor cloud agents share a working directory?No. Cursor documents that cloud agents run in isolated VMs, clone your repository and work on a separate branch, then push changes back for handoff. Nothing is shared until review. Can two people watch the same agent at the same time?On a Murmell canvas they can. A read link shows the windows, the terminal contents and the named cursors as they change. In Cursor, agent work is shared as a link to the finished run. --- ## Murmell vs Devin Source: https://murmell.com/vs/devin Devin is an autonomous engineer you hand a ticket to. You come back to a pull request. Murmell is a canvas where you open several agents on one project and watch the real terminals while they work. The real difference Devin scales by separation. When a task is large it delegates to other Devins, and Cognition describes each one as “a full Devin, running in its own isolated virtual machine with its own terminal, browser, and development environment”. A coordinating session scopes the work, hands out the pieces and compiles the results. Murmell scales by sharing. Every agent on a canvas works in the same checkout on the same cloud machine. Before an agent writes to a path it claims it. The board records one holder per path and refuses everyone else until the holder releases it, and that rule is enforced by the server rather than suggested to the model. A colliding write is snapshotted before it lands. Splitting the work is a decision. Sharing a tree is a negotiation. This changes what you can ask for. Work spread across isolated machines has to be split cleanly at the start, because nothing can be renegotiated once the copies have diverged. Agents in one tree renegotiate as they go: one takes the router file, the next waits for it, then takes it. Where Devin wins Devin is much further along at being left alone. It ships pull requests, picks up review feedback and CI results, and gets handed work from Linear, Slack and the other places your tickets already live. It starts each session from a saved machine snapshot, so your dependencies are installed before it types anything, and it reads its own past sessions to get better at your codebase over time. If success means a ticket going in one end and a merged branch coming out the other, Devin is the product built for exactly that. Murmell asks more of you, because it is a room you sit in. Which to pick Pick Devin when work arrives as tickets that do not touch each other, and you would rather read the result than the run. Pick Murmell when the change is one refactor across one tree, when you want to see the terminals as they type, or when the people you work with need to be on the same screen. Send a read link and they are in the room: the windows, the terminal contents and the named cursors, live. Read links are free and there is no cap on them. Close the tab and the agents keep working. Both can be true in the same week. See what the canvas is. Can two Devins work in the same directory?No. Cognition describes each managed Devin as a full Devin in its own isolated virtual machine with its own terminal, browser and development environment. The coordinating session compiles the results afterwards. What stops two agents overwriting each other on a Murmell canvas?An agent claims the paths it is about to touch. The board records one holder per path and refuses everyone else until the holder releases it, and that rule is enforced by the server rather than suggested to the model. --- ## Murmell vs Google Jules Source: https://murmell.com/vs/google-jules Jules is an asynchronous agent from Google. You point it at a repository, it clones the code to a cloud VM, writes a plan, waits for you to say yes, then opens a pull request. Murmell is a canvas where several agents work in one directory at once and you sit with them while they do. The real difference Jules works on a copy. Google describes it clearly: it “fetches your repository, clones it to a Cloud VM, and develops a plan”, then “creates a PR of the changes”. Tasks run at the same time as each other, and how many you can have in flight is capped by plan. Each one is on its own, working alone in its own clone. Murmell has one clone and several agents in it. An agent claims the paths it is about to touch before it writes, the board keeps one holder per path and refuses everyone else until the holder releases it, and a colliding write is snapshotted rather than lost. Two agents can be halfway through the same feature at the same moment. The other difference is what you see. Jules shows you a plan then a diff. Murmell shows you the terminals, and so does everyone you sent the link to. Where Jules wins The plan step, which is the best-behaved thing in this comparison. Jules tells you what it intends to do and waits, so a wrong assumption costs you a sentence instead of an hour. Murmell has nothing that disciplined; it hands you real terminals and expects you to steer. Jules is also the shortest path from a GitHub issue to a reviewable branch with no new surface to learn. You label the issue and it appears in your pull requests. If your team measures agents by merged pull requests, that is a real advantage. Which to pick Pick Jules for a queue of contained jobs. A version bump or a flaky test, each on its own branch, agreed in advance and reviewed later. Pick Murmell when the job does not fit in one agent’s head, when the files overlap, or when the run itself is the thing worth watching. Closing the tab does not stop anything, and every project gets a private repository that is pushed to as the work happens, including one last push before a machine is torn down. See what the canvas is. Does Jules work in my repository or in a copy?In a copy. Google documents that Jules fetches your repository, clones it to a cloud VM and develops a plan, then creates a pull request of the changes for you to review. Can several agents work on one directory at the same time?On a Murmell canvas they can. Each agent claims the paths it is about to touch and the board keeps one holder per path, so a second agent waits rather than overwrites. --- ## Murmell vs OpenHands Agent Canvas Source: https://murmell.com/vs/openhands OpenHands Agent Canvas is described by its makers as “a local, visual workspace for running AI coding agents”, built for “parallel agents, not single sessions”. Murmell is a cloud canvas of real terminals where those parallel agents share one directory instead of one each. The real difference This is the closest tool on the list, and the difference is one design decision. Agent Canvas runs several agents at once and isolates each in its own git worktree, all visible from one interface. Isolation is how it keeps them from colliding, and a worktree is a real second copy of your files on a branch of its own. Murmell does not isolate them. Every agent on a canvas is in the same checkout, and the safety comes from asking rather than from separating: an agent claims the paths it is about to touch, the board records one holder per path and refuses everyone else until that holder releases it, and a colliding write is snapshotted before it lands. The rule is enforced by the server, not suggested to the model. A worktree keeps agents apart. A reservation lets them stand in the same room. The second difference is people. Agent Canvas starts on your own machine, one browser, one person. A Murmell canvas is a room: send a read link and someone else sees the windows, the terminal contents and a named cursor for everybody in it, live. Closing your tab does not stop the agents. Where OpenHands wins You can read all of it and you can run all of it. Agent Canvas is open source under the MIT licence, starts locally with one command and no Docker required, and connects to a Docker container, a VM you own or a cluster in your own network. The enterprise edition self-hosts inside your VPC. Murmell has no self-hosted option today, and if your code cannot leave your infrastructure the comparison stops there. Its automations go further than ours too. Slack, cron, polling and event triggers ship in the product, and there is a Python library underneath if you want to write your own runner. Murmell launches CLIs on a canvas and nothing else. Which to pick Pick Agent Canvas when the code has to stay on hardware you control, when you want to change the tool itself, or when isolated parallel runs are exactly the shape of your work. Pick Murmell when the agents genuinely need to be in the same tree, or when the run needs an audience. The machine that executes agent code holds no database and no decryption key, so an agent that escapes its box finds nothing worth taking, and work is pushed to a private repository per project. See what the canvas is. --- ## Murmell vs Replit Agent Source: https://murmell.com/vs/replit-agent Replit Agent turns a description into a working application and puts it on the internet. Murmell runs real coding agents on a repository you already have, several of them at once, in one directory. The real difference Replit owns the whole road. It says Agent “writes code, sets up infrastructure, and tests the result”, needs no technical knowledge from you, keeps checkpoints you can roll back to, and takes the app all the way to deployment. The agent is the interface, and the terminal is an implementation detail you are not asked to look at. Murmell is the opposite arrangement. The terminal is the point. You open Claude Code or Codex in a window, you read what it actually printed, and you open a second one beside it in the same checkout. An agent claims a path before it writes, the board keeps one holder per path and refuses everyone else until it is released, and a colliding write is snapshotted before it lands. Murmell does not host anything: work goes to a private repository for the project. Where Replit wins Two things, and both are large. It gets you from a sentence to a URL without leaving the tab, with the database and the hosting handled, and Murmell has none of that. And its multiplayer is older and wider than ours. Replit documents that several people can work in the same project at the same time with cursor presence, and each of them can start their own thread with Agent. Murmell shows guests the canvas live, with a name and a colour on each cursor, but two people typing raw keys into the same terminal is not built yet. If a colleague needs to take the keyboard from you in the same shell today, Replit does that and Murmell does not. Which to pick Pick Replit when the app does not exist yet and you want it running by this evening, or when the people building it would rather not think about infrastructure. Pick Murmell when the codebase is already real, the change is bigger than one agent, and you want to watch the run. Read links cost nothing and are not capped, edit links are capped by plan, and the machine that executes agent code holds no database and no decryption key. See what the canvas is. Does Murmell host and deploy my app?No. Murmell runs the agents and pushes the work to a private repository for the project, including one last push before a machine is torn down. Replit takes an app to a live URL; Murmell does not. Which one lets several people work at once?Both, differently. Replit lets several people edit one project together, with cursor presence and a seat count set by plan. Murmell puts several people around several agents, watching the same terminals live, with unlimited read links. --- ## Murmell vs Vibe Kanban Source: https://murmell.com/vs/vibe-kanban Vibe Kanban is a board. You write tasks, move them across columns, and each one runs a coding agent in its own workspace on your machine. Murmell is a desk rather than a board: windows holding real terminals, all of them in one project directory on a cloud machine. Read this first The project’s own repository carries a notice that Vibe Kanban is sunsetting, with a link to the announcement. It is Apache-2.0 licensed, so the code stays available to run and to fork, but that notice belongs at the top of any comparison rather than in a footnote. Check it before you build a team habit on top of it. The real difference Vibe Kanban organises by task. Its pitch is breadth of agents, listing Claude Code, Codex, Gemini CLI, GitHub Copilot, Amp, Cursor, OpenCode, Droid and others, with a workspace per task and a line-by-line diff you comment on before sending feedback back to the agent. It installs with one command and runs locally. Murmell organises by directory. Agents are not separated: they share one checkout, and each claims the paths it is about to touch before writing. The board keeps one holder per path and refuses everyone else until the holder releases it, and a colliding write is snapshotted before it lands. Two agents can work through the same feature in the same minute. The agents also run on cloud machines rather than your laptop, so closing the tab does not kill them, and other people can be in the canvas while it happens. A read link shows the windows, the terminal contents and a named cursor for each person, live, and read links are not capped. Where Vibe Kanban wins The board itself is a better fit for a queue than a canvas is. If your day is twenty small independent jobs, columns beat windows, and the diff review flow with comments going straight back to the agent is a tight loop. It also runs on your own machine with your own keys, it supports more agents than Murmell launches today, and being Apache-2.0 means you can read it and change it. Murmell is not open source and has no self-hosted option. Which to pick Pick a local board when the work is a queue of separate tasks, the code should not leave your disk, and you want to own the tool. Pick Murmell when several agents have to touch the same files, when the run should keep going without you, or when the people you work with need to see it. Work is pushed to a private repository per project, including one last push before a machine is torn down. See what the canvas is. --- ## Engineering notes from building Murmell Source: https://murmell.com/blog Four things we had to work out to run several coding agents on one directory, each written from the code that does it. The measurements are our own and are stated as such. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container What stops Claude Code on its first launch in a container 25 July 2026 The three prompts that block a fresh Claude Code agent in a container, measured through a real pty. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused Reserving a file before you write it 25 July 2026 Why several agents on one directory have to claim a path first, and what the server does when one of them does not. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace The machine that runs the agents holds no secrets 25 July 2026 Why the half of the server that executes model-written code is kept away from the database, and what the separation cost to build. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one What we found when we put agents on a cloud sandbox 25 July 2026 What a managed cloud sandbox platform allows and refuses, measured against a probe pool rather than read in a document. --- ## What we found when we put agents on a cloud sandbox Source: https://murmell.com/blog/cloud-sandbox-findings The plan said the machine running the agents would keep its network shut and the terminals would dial out to us. A probe pool answered differently on both counts, and the architecture moved to match. Every claim below came back from a real request. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without oneOne channel through the wall, carrying frames both ways, and nothing at all without a token. Everything hung on the WebSocket Agents live in terminals, and a terminal is a stream. If the platform’s entry point had only allowed request and response, the whole shape would have needed rethinking. It allows the upgrade, and it moves frames in both directions. GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to serverWith no token the same request is 403 Unauthenticated. That is the finding that matters most: the machine that executes model-written code has no public surface of its own, and the platform’s identity layer holds the door rather than a secret we invented and have to rotate. The trap is the audience. This is Azure Container Apps dynamic sessions, and the token has to be issued for the dynamic sessions audience. A management audience token, which is the one every example and every CLI hands you first, is refused with a 403 that looks exactly like the unauthenticated case. That is worth an hour of somebody’s afternoon, so it is written down here. One identifier is one container Two different identifiers on the same pool give two different containers, with different hostnames inside them. That is the primitive the product needed: one canvas, one machine. It also means the canvas identifier can be the routing key directly, so there is no registry of tunnels to keep, nothing to reconcile after a restart, and no state that can disagree with reality. Egress cannot be switched off The earlier version of the plan named the platform’s no-egress mode as the native hardening, and that sentence read like a fact. It is unusable. With egress off the machine reaches neither our own control half, nor the code host, nor the model API, and an agent that cannot reach the model is not an agent. With egress on, the code host answered 200, the model API answered 401, which is the answer that proves it is reachable, and our own site answered 200. All three are needed for an agent to do anything. So the isolation cannot come from cutting the network. It has to come from what the machine holds, which is why the database connection and the decryption key were taken off it instead. The one thing the platform had already closed: the instance metadata address is unreachable from inside a session, so there is nothing to block there. The platform decides more of the architecture than the design does. Three details that will bite The proxy announces a ceiling of thirty minutes per request, in a header on the way in. Whether it applies to a WebSocket is not something a document will tell you, and the only way to find out is to hold one open for longer than that. Either way the control half has to be able to reconnect a live link without the browser noticing, which is a thing worth building before you need it. The identifier is not in the environment. A session gets an instance value and nothing else, and the identifier appears only in a forwarded path header. So the machine cannot know which canvas it is serving when it boots. It learns that from the opening frame of the link, which turned out to be the shape the protocol wanted anyway. The lifecycle is not only a timer. There is an exit-driven mode as well, which matters because putting a canvas to sleep is a decision the watcher makes about whether anything is happening, not a decision a wall clock makes. What the measurement changed The plan had the machine dialling out to us, chosen on the assumption that dialling in was impossible. It is not impossible, and now both directions stand up, with a real trade between them. Dialling out needs a registry of tunnels and a shared secret we would have to invent. Dialling in needs neither, because the canvas identifier routes and the platform authenticates, but it couples our control half to one vendor’s API. The decision was to not decide, in the protocol. The relay envelope wraps a connection, not a direction. Dialling in is wired first because it is the shortest path and it is proven. Dialling out stays available the day portability matters more than convenience, and it costs nothing today to keep it available. If you are building the same thing Measure the platform before you draw the diagram. The first version of that section was written from documentation and reasoning, and it read like a set of facts. The probe overturned part of it, including the piece the entire hardening story had been resting on. Write down the guess that cost you an hour. The audience mismatch produced a 403 identical to the one you get with no credential at all, which is the kind of detail that never makes it into a release note and always makes it into somebody’s afternoon. Keep the transport out of the protocol. The direction a connection is opened in turned out to be a deployment detail, and the only reason that was cheap is that nothing in the message format had an opinion about it. --- ## What stops Claude Code on its first launch in a container Source: https://murmell.com/blog/claude-code-first-launch An agent that starts, paints a banner and then waits is producing bytes. Bytes look like success in a log. On a fresh container Claude Code stops three times before it does any work, and each stop is a question asked of a terminal with nobody in front of it. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh containerThe order matters. An agent that has answered the first two still stops at the third. The three stops, in the order an agent meets them stopwhat it asks the first-launch assistantChoose the text style that looks best the workspace trust checkIs this a project you created or one you trust? the provider key checkDo you want to use this API key? The first and the third are global to the machine. The second is recorded per directory. Closing one of them moves the agent forward exactly one stop, which is why anything short of all three reads as progress and delivers nothing. What was measured Every row below is claude 2.1.220 driven through a real pty, one fresh HOME per row. None of it is inferred from the name of a field. seededwhat the agent did nothingblocked on the theme picker settings.json theme alonestill blocked on the theme picker .claude.json hasCompletedOnboardingreached the trust dialog plus projects[resolved].hasTrustDialogAcceptedreached the prompt, “Not logged in” plus ANTHROPIC_API_KEY in the environmentblocked: “Do you want to use this API key?” plus customApiKeyResponses.approvedreached the prompt, “API Usage Billing” Three of those rows contradict what looks obvious. theme on its own does not silence the theme picker. Nobody needs to try that again. hasCompletedOnboarding on its own does silence it, on this version. A key listed in customApiKeyResponses.rejected does not prompt at all. It silently drops the key, and the status line reads “Not logged in”. So a stale rejection has to be cleared for the key being approved, not merely appended past. The trap in the trust key Trust lives in ~/.claude.json under projects[path], and the path is the resolved one. Both places Murmell creates a directory use mkdtempSync, which on macOS hands back /var/folders/… while the resolved path is /private/var/folders/…. Seeding the unresolved key looks completely correct. It writes a plausible entry, the file now says the project is trusted, and the dialog still appears. That one cost a day. export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }realpathSync throws for a path that does not exist, which is a real case: a workspace can be torn down before this runs. Falling back to the path as given writes a useless but harmless entry, and the agent asks the question exactly as it does today. The stop nobody had found The provider key check is the expensive one, because its default answer is 2. No (recommended). A person connects a provider in the interface, the key travels correctly all the way into the environment of the pty, and the agent offers to throw it away with throwing it away pre-selected. What the CLI records is not the key. It is the last twenty characters of one. That was established by driving a pty through the prompt, answering yes, and reading back what the CLI wrote: for sk-ant-api03-PROBE-TAIL-abcdef1234567890 it stored exactly AIL-abcdef1234567890. export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }That it is a suffix is also what makes writing it acceptable at all. A file that recorded whole keys would be one more place a key lives, and the rest of this codebase goes to real trouble to keep a key out of the logs and off the wire. Two answers that look right and are not --permission-mode bypassPermissions does not open the trust gate. It governs tool permissions, which is a different question in the same shape. Pre-seeding the unresolved path does not work either, for the reason above. Both were tried against a real pty before this was written, and both are worth stating so nobody spends the afternoon again. A theme is not a decision. Deleting a file is. This removes questions of configuration. It never removes questions of judgement. Whether a directory is yours is a fact the server already knows on the user’s behalf, and asking an empty terminal does not make it safer, it only makes the product not run. Whether to delete a file or force a push is a different kind of question, and an agent must still ask it. So there is deliberately no --dangerously-skip-permissions anywhere in this path, and the tool allowance stays empty. const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };Empty on purpose, and it has to stay empty. This grants trust in the directory. It is not permission to act inside it. Why the version is read from the binary The onboarding record carries the version of the CLI it was written for, and that value is compared against the installed one. A literal in the source is correct until the image updates its CLI, and from then on it pins an onboarding state that no longer matches the binary: a regression that arrives on somebody else’s release schedule, in production, with nothing in any test suite to notice. So it is read, and when the read fails nothing is written. Not knowing is a first-class answer. Reading it costs a process. claude --version was measured at 40ms warm and 430ms on a virgin HOME, and it creates no files, so the probe does not itself trigger any of the onboarding this exists to pre-empt. Its stdin is closed rather than inherited, because a CLI that decides to ask something must not be able to hang the spawn. Preparing must never cost the session The caller is the path that spawns an agent, immediately before the pty. Failing to prepare costs a keypress. Throwing costs the session. Every error here is swallowed and the worst case is the behaviour we already had. There is a second reason for restraint. ~/.claude.json is shared: agents write to it constantly, and in production they run as the same user with the same HOME, so a read then write can lose somebody else’s concurrent update. Nothing is written when the file already says what it should. Every write lands through a temp file and a rename in the same directory, so a reader sees the old file or the new one and never a truncated one. The mode is 0o600, because that file also holds credentials. If you are spawning agents yourself Assert on the prompt, not on the output. Our own honest production measurement was that agents started, painted a banner and stopped, and the arriving bytes made it read as a success for longer than it should have. Drive a real pty and read back what the CLI wrote. Every useful thing on this page came from doing that, and the two guesses that looked most reasonable were both wrong. Before you silence a prompt, say which of the two kinds it is. Anyone widening a file like this one should be able to answer that in a sentence, and if they cannot, the prompt stays. --- ## The machine that runs the agents holds no secrets Source: https://murmell.com/blog/machine-with-no-secrets An agent that gets out of its container should find nothing worth taking. That is a property of what the machine holds, not of how carefully the container was built. So the process was cut in two, and the half that runs the agents was given no database connection and no decryption key. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspaceEverything that can decrypt something stands on one side. On the other there are agents and a working tree. One process could not be in two places The half that authenticates needs the database: accounts, canvases, share tokens, the encrypted credential for a code host. That database sits on a private network with no public port. The half that runs the agents executes code a model wrote, so it has to sit far away from everything else that network hosts. It was one process doing both jobs, and that is the entire reason the deployment was stuck. Neither shortcut is acceptable. Opening the database to the internet puts a database that also serves other projects on the public road. Moving the executor next to it puts arbitrary code execution beside them. What made the separation cheap The authorisation decision was already a pure function. It does no input or output. It reads no database and no clock. export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheckAnd the access it judges carries four fields: the user, the account session behind that user, the canvas, and the right held on it. So the far half replays the same policy from four fields the near half hands it. The policy is not copied. It is shared, which is the difference between one rule and two rules that will disagree in six months. The call that counting could not find Every call into the accounts store was located, and each one sat inside a handler belonging to the half with the database: sign-up, log-in, resume, log-out, creating and listing a canvas, share tokens, disconnecting a code host. Not one in spawn, input, resize or kill, and none in any board, project, presence or orchestrator handler. The seam looked clean. Then one turned up that the counting could not have seen, because it is not in a handler at all. A helper called authorFor reads a user row, and it is reached from underneath the spawn path and the orchestrator path, so that a commit is attributed to the real person who asked for it. A measurement that walked the line ranges between handlers was structurally incapable of finding it. The answer was not to move the spawn. The frame stays where the pty is, and that half is handed narrow methods instead of a database URL. Narrow is the security property, not the convenience. The identity method answers a name and an email address, and not the user row. The user row carries an Argon2id password hash. Before the split, the machine that executes arbitrary code was receiving password hashes when what it needed was a name. The fix is not a rule that we do not read that field, because a habit degrades silently. The fix is that the answer has no field a hash could ride in, so the reduction happens on the side that has the database and only the result crosses. The same argument runs twice more. The credential method takes a canvas and never a user, so the subject is derived on the side that routed the request: the credential of the owner of this canvas can never widen into any credential in the database. And the canvas method answers three fields rather than the canvas row, because the row also holds the read and edit share links, and the edit one grants write access to whoever has it. Built field by field on the near side, a spread on the far side has nothing to leak. Why it is a role and not two programs Only a small part of the socket server is handlers. The rest is frame validation, connection lifecycle, fan-out, backpressure, keepalive and the sweep that retires idle canvases, and both halves need every line of it. Splitting the files would have duplicated all of it, and two copies of a fan-out is two fan-outs with one bug fixed. Splitting roles duplicates nothing: one binary, one set of shared machinery, and only the active handlers change. export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }Those two predicates are what keeps the property inseparable from the code. No role both skips the database and serves browsers, and there is a test asserting it for every role that exists, so adding a fourth role that broke the rule would fail rather than ship. The accounts option was already required, with no default and no mode that runs without it, precisely so a deployment cannot serve an unauthenticated socket by forgetting a flag. The new role does not relax that. It is not accounts becoming optional. It is the role that runs with no database and refuses browsers outright, accepting only a relayed connection from a process that has already decided who is asking. An unknown role never falls back to the permissive default either: it throws, because a typo in a deploy variable quietly becoming the everything mode is exactly how a sandbox ends up serving browsers. The credential that has to cross anyway Pushing to a private repository needs two things that now live apart: the encrypted credential, which is in the database, and the cloned repository, which is on the other machine’s disk. So the far half never stores the credential. It asks for it immediately before a push, uses it, and forgets it. A decrypted credential exists only as a local variable inside a single call, and there is a test that walks the object graph to prove nothing parked a copy. What the relay costs Terminal output now crosses twice, which is affordable at this size and reversible later without touching the browser. Two properties nearly broke on the way, and both are the same mistake in different clothes: a relay makes a process measure the relay instead of the thing it thought it was measuring. Backpressure was measured on the browser’s own socket. Behind a relay the far half would be reading the near half’s buffer, so a slow browser could fill the near half’s memory while the far half saw a healthy connection. The near half therefore raises the desync itself and stops reading, which pushes the pressure back over TCP where it belongs. Liveness was answered by the browser’s network stack. Behind a relay the near half would answer in its place, and the far half would believe a dead browser was alive and keep its agents attached to nobody. So the death of a connection is propagated rather than absorbed. The bug class a split creates On the half without the working tree, the project registry is not missing. It is empty, and an empty registry answers every question confidently and wrongly. Repository status with no project fills its whole local half with empty strings and zeros, which on that process is a confident description of a working tree that is alive on another machine. That needed a third predicate, and naming it was most of the fix. export function holdsWorktree(role: Role): boolean { return role !== "control"; }If you are building the same thing Look for the pure function before you look for the file boundary. The one decision that governs everything here had no input or output, and that single fact is what turned a rewrite into a launch mode. Count the calls, then assume the count is wrong. The one call that mattered was in a helper, and it was found by reading rather than by grepping. Reduce at the source. Every object that crosses a boundary should be built field by field on the side that owns it, because the day someone spreads it on the far side is the day you find out what it was carrying. --- ## Reserving a file before you write it Source: https://murmell.com/blog/reserving-a-file Give three agents the same repository and they overwrite each other inside a minute. Last write wins, silently, and nobody finds out until the tests do. The obvious fix is a checkout each, and for the case we care about it is the wrong one. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefusedOne holder per path. The write that would have collided is stopped at the board rather than on disk. What a checkout each actually costs A worktree per agent is the right model for three unrelated bugs in a mature codebase. It is not the model for the thing people actually ask us for, which is several agents building one application, split up to go faster. On that case it breaks in four places. The second agent cannot see the first agent’s code. The one writing the API needs a type the one writing the schema finished a minute ago, in another worktree on another branch. It does not see the type, so it declares the type again. You end with three divergent definitions of one thing, and the merge does not reconcile them: it produces a conflict on a file nobody owns. Composing in the open is the whole benefit of working in parallel, and separate checkouts forbid it by construction. On a new project the conflict is maximal rather than minimal. Three agents starting from an empty repository each create a package manifest, a TypeScript config, a bundler config, an entry point and a lockfile. Those are add and add conflicts on generated files, which is the worst case a merge has, and a lockfile does not merge at all. It regenerates. The preview lies. A preview has to serve one tree. Either it serves the integration branch, which is minutes behind the work the person is watching happen, or it serves one worktree, which is a third of the application. And somebody pays for the merge. Either a human in a conflict resolution interface, or a fourth agent burning tokens to repair a fragmentation we created ourselves. A lease, not a mutex So the agents share one directory, and a reservation is what makes that survivable. A claim is a set of paths, an agent, a mode and an expiry. It prevents nothing physically. It declares an intention, and it gives the system the right to judge a write. There are two modes. An exclusive claim has one holder. A shared claim announces a read, which is how an agent says it depends on a file and gets told when the owner of that file changes it. A claim never blocks. A refusal comes back immediately, and it carries everything the refused agent needs to do something else instead. export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }The holder, what the holder is working on, how many seconds are left, and what to do now. An agent that queued on a lock would burn tokens sitting still, so the refusal tells it to take other work in its own scope, or to message the holder, or to post itself as blocked so the orchestrator can re-plan. Expiry is a lease and not a deadline. Any board call by an agent, and any write the watcher observes on a path it holds, pushes its expiry out by a full term. An agent that is working never silently loses its lease. The default term is fifteen minutes, the ceiling is an hour, and one claim covers at most fifty paths. Death needs no heartbeat, because the server owns the pty. When the process exits, every lease of that session is released at once, the roster marks it as gone, and the orchestrator is told which paths it was holding and which task is unfinished. The expiry only ever covers the agent that is alive but stuck. A person can break a lease from the canvas. The orchestrator deliberately cannot. Breaking the lease of a live agent that is genuinely writing is the most reliable way to manufacture the collision the whole mechanism exists to avoid. There is also a ceiling on how often an agent may ask. Past thirty board calls in a rolling minute the answer is an explicit refusal carrying a retry time, returned as a value the agent can read rather than thrown as an error, because an agent cannot act on an exception. Compliance is an optimisation, never a condition of correctness. The rule is judged, not trusted The server owns the filesystem, so it does not have to believe an agent that says it claimed something. A watcher sees every write and asks who it belongs to. classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassificationThe order is fixed. The agent’s own hook report first, which is ground truth wherever the CLI supports hooks. Then the live claim on that path. Then the single agent whose declared scope matches it. Then nobody, honestly recorded as nobody. A scope match is used only when exactly one agent claims that territory, because two overlapping scopes is an invalid plan and guessing between them would put a lie on the canvas. That is the whole reason this works with models that do not cooperate perfectly. An agent that forgets to claim still gets its writes attributed and still gets caught writing into somebody else’s path. When a write lands on somebody else’s path The snapshot is committed before the collision reaches the screen, so the revert the canvas offers is always real. Ordering it the other way round would give people a button that sometimes has nothing behind it. Then both sides are told. The offender is told to stop and to revert if it can, so it does not keep going. The holder is told that its file moved underneath it and that it should re-read the file before trusting it, which is the message that stops a good agent building on a corrupted assumption. The third violation by the same agent stops being a message and becomes a question to the human: pause it, re-scope it, or let it continue. An agent that has broken the same rule three times is not going to be fixed by a fourth notification, and the loop diverges if nobody interrupts it. Attribution comes free Because the server knows who held which path at the moment it changed, every write is attributed. The commit message names the agent alongside the file. A human reviews one diff that can be coloured by author, and gets blame per agent with no branch per agent, which was the main thing a worktree each would have bought. What the agents did with it Measured on our own two-agent runs: 1.8 board calls per turn, two writes out of two covered by a claim, and two refusals to overwrite a peer. It is a small sample and our own observation rather than a benchmark, and it is stated as such. The interesting figure is the first one. Nobody polled. Agents used the board roughly twice a turn, which is what a mechanism looks like when it is cheaper to use than to work around. The two refusals took insisting: we had to push before an agent would overwrite a peer at all. If you are building the same thing Put the enforcement where the filesystem is. A protocol the model is asked to follow is a suggestion. A watcher that attributes writes is a fact, and the difference shows up the first time a model is having a bad afternoon. Make refusal cheaper than waiting. A refusal that arrives instantly with the holder, the remaining time and an alternative is something an agent can act on. A blocking lock is an invoice. Snapshot before you notify, not after. The order is the difference between a revert button and a lie.