Sandboxed Execution, Isolation, and Publication Boundaries

4. Tradeoffs and alternatives

Local worktrees are fast and observable but share the host. Containers improve process and filesystem isolation but may share a kernel. Remote VMs strengthen host separation at higher latency, cost, provider risk, and orphan complexity. Risk-proportional policy should choose the boundary.

Giving the sandbox publication credentials simplifies the architecture and destroys separation of duties. The outer publication step is more work but keeps untrusted code away from the durable repository write identity.

5. Current Mission Control Implementation

GitHub main includes the codex/v1 adapter contract and Factory host readiness, but not the complete production worker.

Study commit 9d5f8e3 on draft PR #64 implements an attempt-specific local worktree worker. It claims a durable lease, renews heartbeats, validates the frozen worktree and code scope, runs Codex, blocks out-of-scope changes, commits, mints an ephemeral repository-restricted GitHub App token, pushes, and creates or reuses an exact PR. Terminal reporting requires the active matching lease.

Todo 024 records a real GitHub App proof: branch and commit were created, and PR #61 opened with passing checks. The proof required direct control-plane mutations because the browser Mission path could not yet carry all policy and receipt data. The browser-only golden path and complete UI state matrix remain open.

Remote sandbox documents in the local Mission Control folder are uncommitted proposals, not product capability. They define a strong authority and threat model, but the provider proof is blocked because the selected exe.dev plan has zero VM capacity and the Product Owner declined an upgrade. No repository, model, or production credential was sent to a VM.