Mission Control: an agent-first task manager that runs Claude Code sessions locally

The problem is not task tracking, it is unattended agent sessions

Linear, Asana and Notion assume a human typing into a form. Mission Control assumes the opposite: the agent does the work and the human answers questions. The README is explicit about the failure it targets, describing agents as black boxes where nobody can say what is running, whether it finished, or whether it went off the rails three hours ago. That is a different problem from backlog grooming. The intended user is a solo entrepreneur running several ideas at once, delegating research, MVP builds and launch actions to agents, and needing one place where task state, agent reports and approval requests land. The pipeline the README sketches runs Idea, Research, Go/No-Go, Build MVP, Launch, with the human making three decisions and agents doing the rest. If you are a team of five splitting work across Jira, this is not aimed at you.

Tasks are the unit of dispatch, and the daemon is the scheduler

The mechanism visible in the README is a loop. Tasks live on an Eisenhower matrix and a Kanban board with Not Started, In Progress and Done columns. An autonomous daemon runs as a background process, polls tasks, spawns Claude Code sessions and enforces a concurrency limit. Pressing play on a task card spawns a session directly; the card shows live status and the task moves to done with an inbox report and an activity log entry on completion. Continuous Missions extend this to a whole project: tasks auto-dispatch as others complete, dependency chains are respected, and decision-blocked work is skipped. Loop detection watches for agents stuck failing, and after three attempts escalates to a user decision with retry, skip or stop options. Session resilience covers the timeout case: agents that hit max turns re-spawn continuation sessions, with the progress preserved in task notes and subtasks, and configurable maximums per task and per inbox response. The data flow is therefore task to session to report to inbox, with cost and token usage captured from every session and shown on an Autopilot dashboard.

The token-optimized API is the part other agent tools will copy

Agents read and write tasks through an API the README calls token-optimized, with filtered queries and sparse field selection. The claimed compression is 92 percent, roughly 50 tokens against 5,400 for the equivalent unfiltered response. Treat that number as a design target rather than a benchmark, since no measurement method is given, but the direction is sound: an agent polling a task list every few seconds pays for every field it receives. All nine GET endpoints support limit and offset and return a meta object with total, filtered and returned counts, which is what you need to page through work without loading everything into a context window. The same API is how agents report progress to the inbox and escalate questions. If you are wiring your own agent framework into this rather than using the built-in Claude Code path, the API is the integration surface, and sparse field selection is the reason it is usable at polling frequency.

Running it locally: what the README actually specifies

The README does not include an install section, so the honest answer is that the exact commands are not in the supplied material. What is specified: the project is TypeScript, the app lives under a mission-control directory in the repository, and the default branch is main. The README references a CI workflow at .github/workflows/ci.yml, which is the place to look for the build and test commands the maintainer actually runs. The operational commands it does name are in-app rather than shell: /orchestrate spawns all agents on pending work at once, and the daemon runs as a background process that polls tasks and spawns Claude Code sessions. Configuration keys it names are behavioural rather than literal: max continuations per task, max continuations per inbox response, and spend limits and approval workflows on execution actions. The README claims 193 automated tests, which is a starting point for reading the test suite, not a substitute for running it. You will need Claude Code available locally, since the execution path is built around spawning its sessions.

Agents that move money and post content need a threat model, not a feature list

The README says agents can post to X, send ETH and call APIs, with approval workflows and spend limits at every step. It does not describe how those limits are enforced, where keys are stored, or what happens when an approval is requested and nobody answers. That is the gap that matters most, because the same document argues that unleashing agents without structure is a liability. A local-only design removes one class of risk, since credentials are not handed to a third-party host, but it concentrates another: everything runs on your machine with your keys. The inbox stop button kills the process tree and prevents continuation chains from spawning, which is a real control, but it is a manual one. Loop detection after three failures is also reactive. If you plan to let an agent hold a wallet or a social account, read the execution code before you read anything else, and start with spend limits set low enough that a bug is annoying rather than expensive.

Where it stops being the right tool

Mission Control is single-player software. The approval queue, the inbox and the decision prompts all assume one human. There is no mention of roles, permissions, shared workspaces or an audit log for someone else to inspect, which rules it out for a team that needs to show a reviewer who approved what. The local-only stance is a deliberate trade: no cloud dependency and no vendor lock-in, but also no hosted option, no uptime guarantee and no support contract. The version badge reads 0.10 and no releases were retrieved from the repository, so treat it as pre-1.0 software whose interface can move. The AGPL-3.0 licence is the other constraint worth naming plainly: if you modify it and let users interact with it over a network, the licence's source-availability condition applies to your modified version. That is fine for personal use and a genuine consideration if you plan to build a hosted product on top. For legal questions, ask a lawyer, not a review.

Against a human-first tool, and against a raw agent framework

The obvious comparison is Linear or Notion, and the README makes it directly: those tools were built for humans typing into forms, this one for agents reading and writing through an API. The practical difference shows up in the inbox. In a human-first tracker, a blocked task sits until someone notices. Here, an agent posts a question, waits, and the answer unblocks the work, with the decision recorded alongside the task. The other comparison is a bare agent framework like the Claude Code CLI on its own. That gives you execution but no matrix, no dependency-aware dispatch, no per-task cost breakdown and no continuation logic when a session times out. Mission Control is the coordination layer around sessions you would otherwise track in a spreadsheet. If your work is a handful of long-running agent jobs with no prioritisation question, the CLI plus a notes file is less machinery.

Editorial conclusion

Adopt Mission Control if you already run Claude Code locally, you are the only human in the loop, and you want task state, spend caps and an inbox attached to agent sessions rather than scattered across terminals. Do not adopt it if you need multi-user permissions, an audit trail for compliance, or a hosted service with an SLA: the README describes a local tool with no cloud dependency, the licence is AGPL-3.0, and no releases were retrieved. Before trusting it with real money, verify two things yourself: how the spend limits are actually enforced in the daemon, and what the approval workflow does when an agent calls an external API while you are asleep.

Official sources

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