Inside the sandbox

Inside an Isolation session, the agent has its own MCP server, called isolation, started by isolation-server and registered with the harness over ACP. It is not the remote MCP at mcp.isolation.cloud and it is not a door: nothing outside the sandbox can connect to it, and it holds no credential that would let the agent out. It exists so the agent knows where it is and can do what its job needs: keep a note across sessions, talk to the other agents and to the people in its conversation, and open or share a window on the session it lives in. An agent in your editor connects the other way round, described on connect from Claude Code, Codex, Cursor.

What the agent gets

How does the memory work?

memory_read returns a short markdown note; memory_write replaces it, or adds to it with append: true. The note is capped at 32 KB; a longer one is refused with a request to condense it. It lives at /workspace/.isolation/agents/<agentId>/memory.md, under the workspace tree, so it is saved with the workspace, comes back in the next session on any server, and is one note per agent per workspace. The agent reads it at the start of every turn; how it fits with conversations is on memory and conversations.

{ "name": "memory_write", "arguments": { "content": "## Decisions\n- Tests run with `npm test`, not `make`.", "append": true } }

How do agents talk to each other?

thread_send addresses another agent in the same session by name or by agent view id and waits for its answer, up to twenty minutes. It goes over loopback, from one agent's bridge to another, and never leaves the sandbox. The agent cannot send to its own thread. It is for delegating and asking; for everything else the agents coordinate through the shared files under /workspace, as several agents in one session describes.

How does the agent talk to people?

When the session is connected to a chat, the chat_* tools are the agent's side of that conversation. chat_context says which app, which channel or direct message, and who sent the message being answered; the agent calls it first when a request says "here" or names a person. chat_history reads the recent messages and chat_members lists the people and agents present. chat_reply speaks in the same thread before the turn ends, chat_post posts unprompted (a build finished, a test broke), and chat_notify_owner sends a direct message to whoever launched the session. Each is scoped to the calling view's own thread: an agent reads and answers only the conversation it is part of. Outside a chat, chat_context says so.

Which actions are forwarded, and how

The sandbox can reach loopback and nothing else, so the answer to "open the preview" or "what do the logs say" is not inside it. The agent parks the call on its bridge; isolation-server long-polls that bridge, picks the call up, and forwards it to Isolation Cloud as the agent actor. There it runs the one action body every other door runs, pinned to this session: the sessionId argument is overwritten with the agent's own session, whatever it asked for. ssh_command is view_connect on the session's terminal. The agent's rights are fixed at seeing the organization and acting on its own session, and only the actions marked for everyone accept it. It can save, open and close windows, share a web preview's link and read the logs; it cannot stop the session, launch another, or touch a workspace. Which ones are open to it is in the table on what an external agent can do. Each forwarded call is logged with the harness (claude, codex, goose) as its channel.