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.

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.

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 recovery is `systemctl enable --now tailscaled`, followed by strict-host-key SSH and a silent sentinel run. Do not recreate an `old-agent` tunnel: `old-agent` is compute-only.

## Picking the agent

The `agent` field is **one of the agent names registered on the platform**. The two universal agents are `build` and `plan`. Some setups also offer `ana` (audit) and `paloma` (coordinator), but **availability varies per installation and workspace** — do NOT assume all four are available. The right one depends on the work:

- `build` — general implementation agent. Use for "build this project", "scaffold this repo", "implement feature X". Default for coding tasks.
- `plan` — research/planning agent. Use for "investigate options", "draft an architecture", "compare libraries", "write a draft", "research and summarize". No code (or minimal code). Default for research/article/analysis tasks.
- `ana` — analytical/audit agent. **May not be available** — check first or use `build` if you just need code review.
- `paloma` — coordinator/operator agent. **May not be available.**

> **Pitfall — agent availability and naming vary by deployment.** `agent` is a registered platform profile and `backend` selects the execution backend; they are logically separate, but current deployments may register backend-aligned agent IDs such as `codex` in addition to profiles such as `build` and `plan`. Do not hard-code a universal agent list. Use the live tool schema/catalog or a previously verified route. For Codex, always set `backend="codex"` and the exact OpenAI model ID in `model_override`; u