The sessionboxer MCP: what the agent knows and what it may do

The agent knows it runs inside Sessionboxer, and which session. Its briefing opens with the session's name and environment, .sessionboxer/session.json in the Workspace (/workspace, C:\workspace or /Users/agent/workspace) has the id, title, URL, agent, model, environment, branch, snapshot count, what it was forked from and who created it, kept current by the box, and a built-in sessionboxer MCP server (next to desktop) answers whoami (all of that plus status, usage, the queue, your open Terminals, attached PRs, the current verification run) and docs (a question about Sessionboxer, answered from this guide, which ships in the box). Ask the agent "where are you?" or "how do I enable Docker in the box?" and it answers from those, not from memory. The box has no route to Sessionboxer's API: the MCP talks to the box's own daemon, which forwards over the connection Sessionboxer already holds to it, so there is no token in the box and a box can only ever speak for its own session.

With the same server the agent acts on its session, the way you would from the UI: attach a pull request and read its comments and checks (pr_attach, pr_list, pr_items, mark them addressed), snapshot now, rename the session, put a follow-up for itself in the queue (you see it there and can edit or drop it), start a verification run with its own brief (shown in the Auto QA pane above the cases), read what is in your Terminals (terminal_list, terminal_read), open a pane for you (ui_open: the page switches to Terminal, Code, PRs, Auto QA or Context, only if you are looking at that session and not typing; with a command a new Terminal opens running it visibly), send you a notification, and read the public settings. Every action appears as a small marker in the chat where it happened ("attached PR #12 (owner/repo)", "took Snapshot 3", "renamed the Session to …", "opened verification run …"), so the transcript says what the agent did.

If you allow it, the agent works across sessions: list them and read another's status and last reply (never its whole conversation), create a session with a first prompt, fork its own (a handoff it writes itself starts the fork at once, without the hidden handoff turn), message another session's agent — the prompt shows there as from Session X (its Agent), never as your words, and the sender's chat shows sent a message to Y — wait for that session's turn, stop the sessions it created, and schedule prompts (the same Scheduled tasks). Sessions an agent created say child of … under their name in the sidebar and the parent lists its children. Limits keep a runaway or a prompt-injected agent in check: at most 3 alive children per agent and a global cap on agent-created sessions (Global settings → MCP & connectors → sessionboxer, 10 by default); a chain of agents prompting agents stops after 4 hops; one message in flight per target; a session cannot message itself; stopped children do not count.

Policy. Global settings → MCP & connectors → sessionboxer sets the default for new sessions and each session's Advanced… → Agent tools overrides it: Off (the agent gets no sessionboxer MCP at all; the briefing still tells it what Sessionboxer is), This Session only (self-knowledge and the actions above on its own session, forks of itself, schedules that target itself) or All Sessions (the default: the cross-session tools too). When the Agent creates a Session — Ask me (default) or Do not ask: with Ask me the agent gets pending and a card appears in the chat, "Claude Code wants to create a Session 'Backend tests'" with Allow and Deny; the agent waits for your answer (approval_wait), and a card nobody answers in 10 minutes is denied as expired. Settled cards stay in the transcript with a link to the session they created. A change of policy applies to the running agent at its next turn; Off removes the server from the agent's MCP list then. Windows and macOS sessions have the same server and file: the MCP runs in the Linux box and the agent in the VM reaches it through the same bridge as desktop. Every tool of the server, with its parameters, limits and what it returns, is in the MCP tools reference.