/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."
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.

A conversational `start_mission` is a **worker of this chat**. Hermes stamps `origin_session_id`, enrolls the mission, and the terminal webhook folds the result back here. End the turn after dispatch — do not poll, and do not invent a cron just to wait. Controller/cron ticks are different: they pass `project` and report on the next tick / project route.

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`, or pass both `mission_id` and `idempotency_key` to `workspace_bash`. Both return a durable job ID immediately through the same admission path; retry the same submission with the same key. Without that pair, `workspace_bash` is a short diagnostic (60 seconds by default, maximum 120) that is killed at timeout. Shell command text is not used to infer durability. Consume the job completion callback; do not keep an agent polling or launch another build to inspect the first.

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

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 mission state. 2. **Workspace** — container/host execution environment selected by `workspace_id`; examples include project workspaces and the dedicated `dgx-spark` workspace. 3. **LLM backend** — the `backend` field (`codex`, `claudecode`, `opencode`, `gemini`, `grok`); this selects the agent/model transport, not a physical machine. 4. **Remote node/build worker** — extra compute reached through sandboxed-node or `/api/remote-build`; current documented general runners are `babylon`, `nippur`, and `ashur`, while the Lean build fleet also includes `dgx-spark`. 5. **Adjacent runner** — e.g. a GitHub Actions self-hosted runner. This is not automatically a sandboxed.sh remote node even if it runs on the same machine.

For inventory questions, report all SSH-reachable machines separately from the subset registered as sandboxed.sh compute. Date any “currently deployed” claim unless live state was checked via `GET /api/remote-nodes` and `GET /api/health/fleet`.

**Production DGX routing incident rule.** If `disk-sentinel` reports only `dgx-spark` unreachable, check `systemctl is-enabled tailscaled`, `systemctl is-active tailscaled`, and `tailscale ping -c 2 100.77.4.93` on `agent-core` before changing keys or topology. The expected rec