Mission Control spawns Claude Code sessions and then has to rein them in

An AGPL-3.0 project whose last commit is dated 2026-04-01

The repository is not archived, and it has no GitHub releases, so there is no tagged build to pin and nothing to download from a release page. The last commit on the default branch is dated 2026-04-01, which puts the project roughly six months without a recorded change as of this writing.

The license is AGPL-3.0, which is an unusual fit for the product's own pitch. The stated advantage of running locally is that there is no cloud dependency, no API key leaked to third parties and no vendor lock-in. AGPL is the copyleft variant that reaches past distribution: a modified version offered over a network has to offer its source to the people using it. For a locally run tool that keeps its data on your own machine, the clause has less bite than it would for a hosted service, but anyone who plans to fork it and run a shared instance is signing up to publishing changes.

Quality gates are described even though nothing is released. A GitHub Actions pipeline runs typecheck, lint, build and tests on every push and pull request, and the test suite is described as 193 automated tests in Vitest, covering validation schemas, data layer operations and the full agent communication flow. What the pipeline does not do is publish anything.

The visible part of the README also stops before any setup. It walks through the product idea and the feature list, then ends inside the Field Ops section, mid-sentence on the 64-service catalog. No install command, no run command and no configuration file appear in what is here.

Every agent is a spawned Claude Code session

The runtime is not abstract. One-click execution presses play on a task card and spawns a Claude Code session, with live status indicators, success and failure toasts, and an automatic completion sequence that moves the task to done, posts a report to the inbox and writes an activity log entry. The Autonomous Daemon is the same idea without the click: a background process that polls tasks, spawns Claude Code sessions, enforces concurrency and exposes a real-time dashboard.

That design has consequences the feature list implies rather than states. Sessions are processes, so they have a process tree, which is why the inbox stop button works by killing the process tree and by preventing continuation chains from spawning at all. Cost tracking works the same way, reading cost and full token usage, input, output, cache read and cache creation, out of every Claude Code session and attributing it to a task on the Autopilot dashboard with per-task breakdown and running totals.

Session resilience is the third piece. An agent that times out or hits its maximum turns does not simply fail; it re-spawns as a continuation session, and the progress it made is preserved in the task's notes and subtasks rather than in the session. Failure events record error details, the number of sessions used and the agent involved, and a failure report is posted to the inbox automatically.

Read together, the runtime is a supervised process supervisor wearing a task manager's clothes.

Two retry philosophies in the same feature list

Retries are governed twice, with different rules, and the difference is easy to miss because both features are described as resilience.

Loop detection is the fixed one. It watches for an agent stuck in a failure loop and, after 3 attempts, escalates to a user decision with three options: retry differently, skip, or stop. The number three is not described as configurable.

Session continuations are the tunable one. Max continuations are configurable per task and per inbox response, so the same project can let one agent retry aggressively and another stop after a single turn.

The two mechanisms also trigger on different conditions. A continuation is spawned after a timeout or after the session reaches its maximum turns, which are budget events. Loop detection escalates after repeated failures, which are outcome events. An agent that keeps timing out will accumulate continuations without ever tripping the loop counter, and an agent that fails fast three times will reach a human without any continuation at all.

The escalation target in both cases is the same place, the decisions queue, which sits next to the dashboard and the inbox as one of the three supervision surfaces.

The API drops context by 92 percent and reports what it dropped

Agents are not supposed to read whole records. The token-optimized API is built on filtered queries and sparse field selection, and the claimed effect is 92 percent context compression, roughly 50 tokens against roughly 5,400 for the naive shape. That is the number that makes an agent-first task manager different from a human one, since the budget an agent spends per turn is what decides whether delegation is cheaper than doing the work.

Pagination is described across all 9 GET endpoints, each taking `limit` and `offset`, and each returning a `meta` object with three numbers: total, filtered and returned. Keeping filtered separate from total is the detail worth noting. It tells the agent that a query it made was narrowed server side, rather than leaving the agent to assume it saw everything that matched its filter.

The rest of the surface is defensive. Every page has an error boundary with a retry button, plus a global error handler for crash recovery, which is consistent with a tool that supervises long-running background processes and gets navigated away from mid-request. Global search is a Cmd+K palette across tasks, projects, goals and brain dump entries.

Accessibility is treated as a feature rather than an afterthought here, with ARIA live regions announcing drag-and-drop moves to screen readers and focus trapping on detail panels, both of which matter more than usual in a board where dragging a card is a primary action.

The no-leak claim sits next to a catalog of 64 external services

The Execute pillar is where this stops being a task tracker. Agents are described as taking real-world actions, posting to X, sending ETH and calling APIs, with approval workflows and spend limits at every step. Field Ops is the section that covers it, and it opens with a 64-service catalog spread across 16 categories, pre-configured, with setup steps for each.

That catalog is the other side of the privacy claim. The pitch is that nothing leaks to third parties because the app runs locally and holds no cloud dependency. An install that can post to social media, move cryptocurrency and call 64 pre-configured external services is an install holding outbound credentials for all of them, stored somewhere on the operator's own disk. Local storage moves the risk rather than removing it, and the operator inherits the key rotation.

The approval workflow and the spend limit are the stated brakes, and both are named without their mechanics in the part of the document that is visible. The Field Ops list ends partway through the sentence introducing the catalog, so the setup steps, the limits and the defaults are not spelled out here.

What is clear from the surrounding text is the shape of the loop: continuous missions can run an entire project with one click, dispatching tasks as others complete, respecting dependency chains and skipping work that is blocked on a decision, with a progress bar and a stop button.

Two prioritization models with no stated bridge between them

The product carries two different ways of ordering work and does not say how a task moves between them. The Eisenhower matrix is the first, with drag-and-drop between Do, Schedule, Delegate and Eliminate, and it is the one the Prioritize pillar is built on. The Kanban board is the second, with exactly three columns, Not Started, In Progress and Done, and it is the one the orchestrator and continuous missions operate on.

Above both sits a goal hierarchy, long-term goals with milestone tracking, progress bars and linked tasks. A multi-agent task names a lead agent plus collaborators, and the orchestrator is invoked as `/orchestrate` to spawn all agents on pending work simultaneously.

The interesting gap is between the quadrant and the column. A task in Schedule or Eliminate is not obviously a task with a Not Started state, and a task with dependencies that continuous missions can chain is not obviously a task that belongs in a four-quadrant triage. The orchestrator spawning every agent on pending work at once also sits awkwardly with the delegate-early rule, since delegating is supposed to be a deliberate quadrant choice.

The crew itself is fixed in size at the low end: six built-in agents, plus unlimited custom agents with their own instructions, and a skills library of reusable knowledge modules that get injected into agent prompts.

Skills and agent command files are kept in sync in both directions

The repository layout explains the runtime. At the root sit `commands/`, `skills/`, `.claude/`, `.claude-plugin/`, `CLAUDE.md` and `scripts/`, while the application itself lives in `mission-control/`. The agent commands are therefore files in this repository rather than rows in the database, which is why the sync mechanism is worth reading.

Skills injection is described as bidirectional. Skills from the library are embedded into agent command files in both directions, agent to skill and skill to agent. In one direction the library feeds an agent's prompt; in the other, whatever ends up in the agent's command file is reflected back into the library entry. A one-way injection would be simpler, and the reverse direction is what makes a skill edited by hand during a session reappear in the library rather than being overwritten by the next injection.

The AGPL-3.0 license file sits alongside that arrangement, as does a CONTRIBUTING.md and the GitHub Actions directory that runs typecheck, lint, build and tests. The commands directory and the Claude plugin metadata at the root mean the project is itself shaped as something Claude Code can load, which is coherent given that its runtime spawns Claude Code sessions.

The four supervision surfaces named for a human operator are the dashboard, the inbox, the decisions queue and the Eisenhower board, and every one of them exists because an agent can end a turn needing an answer.

Editorial conclusion

This is a control surface built on a specific assumption: the agent runtime is Claude Code, spawned as a process, with task notes and subtasks standing in for a session's memory. That assumption is what makes the cost tracking, the continuation logic and the stop button work, and it is also what limits the design, since nothing here describes a non-Claude backend. Two things to settle before adopting it. The retry rules differ, with loop detection escalating after a fixed three attempts while continuation counts are configurable, so decide which behaviour you actually want per task. And note that the agents described here post to social media, send ETH and call third-party APIs with approval workflows and spend limits, which means the local install holds outbound credentials for a large catalog of external services.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. MeisnerDan/mission-control on GitHub
4. README