Sandboxed.sh Missions

Sandboxed.sh Missions

Delegate coding/automation tasks to isolated containerised missions via the mcp_sandboxed_assistant_* MCP. Each mission runs in a chosen workspace (a fresh container with a known set of init scripts and pre-installed tools) and executes the prompt autonomously via a configured agent. Intermediate tool calls stay in the mission's own context.

start_mission with project / track is a worker. Confirm pending/active, then end the turn — do not poll, do not invent a cron just to wait, and do not wait for a callback in this chat. Completion is a mission row; a controller tick (Orb cron page) reconciles it. origin_session_id is v1 plumbing when a Hermes plugin injects it.

When dispatching against a project roadmap, also pass the declared track, its acceptance_criteria, and a stable retry-safe idempotency_key. The server reserves the track owner and links the mission as one durable intent; reusing the key returns the original launch instead of duplicating work. Mission completion alone does not satisfy the track. Accepted criterion evidence at the governed artifact version must be recorded separately.

For long workspace commands, use start_workspace_job with a stable idempotency_key. The unified MCP returns an action receipt first. Read get_action(action_id) to obtain the job ID, then inspect that existing job. workspace_bash and the duplicate worker launch aliases are retired.

With sandboxed-mcp, every mutation (including ask, resume, cancel, task and project updates) requires an idempotency_key and returns a durable action receipt. Retry an interrupted submission with the same key and arguments. A completed action means its tool call completed; inspect the returned mission or job to determine whether the underlying work completed. For reconciliation_required, inspect that target before doing anything else; never create a fresh key to bypass uncertainty. Calls use a 60-second transport budget; the accepted work continues on Core after a disconnect.

Every executor may launch a cloud mission using start_mission and its cloud selection. Discover available accounts/models through list_cloud_accounts and list_cloud_models; owner account quotas remain enforced. Credentials are supplied by the trusted launcher. Never request Core's signing secret or copy the operator's login token into a harness. Executor access covers its own mission and direct children; Core supplies the parent identity.

This is not the same as delegating to a CLI coding agent (Claude Code, Codex, OpenCode) via the terminal tool. The MCP runs an entire conversation loop inside the container; the CLI agents are interactive programs you spawn in a single terminal() call. Use this skill for isolated multi-step research/coding, or work that needs a specific pre-baked workspace (e.g. tailscale-ubuntu, minecraft, dgx-spark).