/sandboxed-sh-missions

name: sandboxed-sh-missions
description: "Delegate coding/automation tasks to sandboxed.sh missions via the mcp_sandboxed_assistant_* MCP. Each mission runs in an isolated container (workspace) with a chosen agent profile and a self-contained prompt. Use this skill whenever the user wants to 'launch a mission', 'sandboxed', 'spawn a worker', or delegate a multi-step coding/research task that should run in a clean environment. To consult another model (review, second opinion), call consult_model(model=..., question=...): it starts the read-only opencode child for you."
license: MIT
metadata:
  hermes:
    tags: [Sandboxed, Missions, MCP, Coding-Agent, Delegation, Isolation, Workspace]
    related_skills: [ai-coding-agents, github-workflow]

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`).

To withdraw work still queued, call `cancel_action(action_id, idempotency_key)`. Read its receipt: `cancelled=false` means dispatch already started or settled; use the existing mission/job cancellation tool after inspecting the target. Cancelling an MCP request or closing stdio does not cancel accepted work.

When to use

• User says "lance une mission", "sandboxed", "spawn a worker", "delegate to a coder in a clean room".
• Task is non-trivial: a project to scaffold, a refactor, a test suite, a multi-file code review.
• You want isolation: the work must not touch the host's working state, dependencies, or secrets.
• The task benefits from a specific workspace's pre-installed tools (Python/uv, Node/bun, gh CLI, Tailscale, etc.).

**When NOT to use:**

• Single trivial edit → `patch` / `write_file` is faster and cheaper.
• Task needs back-and-forth with the user → subagents can't use `clarify`.
• You need a long-running daemon → use `cronjob` or `terminal(background=true)` instead. Missions terminate when the agent emits its final message.
• Task is purely a tool call with no reasoning → `execute_code` is more direct.

The MCP surface

| Tool | Purpose | |------|---------| | `mcp_sandboxed_assistant_list_workspaces` | List all workspaces (containers) you can target. | | `mcp_sandboxed_assistant_start_mission` | Launch a new mission: pick workspace + agent + prompt. | | `mcp_sandboxed_assistant_get_mission` | Fetch a mission's current status and metadata. | | `mcp_sandboxed_assistant_get_mission_events` | Read transcript/trace of what the agent did. | | `mcp_sandboxed_assistant_list_missions` | List recent missions (optionally filtered by status). | | `mcp_sandboxed_assistant_list_active_missions` | Only the in-flight ones (pending/active/blocked/awaiting-user). | | `mcp_sandboxed_assistant_send_message_to_mission` | Resume a mission with a follow-up prompt (for `awaiting_user` missions). | | `mcp_sandboxed_assistant_cancel_mission` | Stop a mission. Returns "not found" if the mission is already gone — that's normal. |

Terminology: backend, workspace, host, and remote node are different layers

When a user asks which “servers/backends” sandboxed.sh uses, answer by layer instead of conflating them:

1. **Control-plane host** — runs sandboxed.sh production and orchestrates missio