capcomd 0.12.0

Fixes capcomd restarting after every Mac sleep, and gives the desktop window a sidebar, ⌘K Search, a Needs you reel,
and pane splits.

• capcomd no longer restarts after your Mac sleeps. Since 0.11.0 (Rivet 3.1.1) the engine stopped itself on every wake
  after a sleep longer than about 30 seconds, and capcomd serve exited with it ("engine on :6420 stopped answering")
  until launchd started it again. Now serve starts the engine again in place, on the same data, and logs one line
  ("the engine on :6420 exited …; starting it again on the same data"). The harness API stays open, and agents that
  were running when the Mac went to sleep carry on and finish.
• The capcomd window has a sidebar. Open it with ⌃⌘S (or ⌘, View › Toggle Sidebar, or the sidebar button next to the
  traffic lights): your agents are listed by what needs you (Needs you, Running, Finished), each project as a label with
  where it runs, and the window shows one agent at a time beside it. Click an agent (or use ↑ ↓ and Return) to show it;
  its ••• menu messages, pauses or resumes it, or copies its ID. The Needs you hand and the Needs you heading open
  the Needs you reel in the agent's place. The window remembers whether the sidebar is open.
• Folded (the default), a rail on the window's left holds Home, the Needs you hand with how many agents need you, and
  Settings; Home moved there from the title bar, where the sidebar button now sits.
• Desktop: ⌘K is now Search, a native palette in the style of Spotlight (system vibrancy, accent selection). One list finds what needs you (asks
  and usage limits), agents by their own titles, projects and commands, ranked in that order, as you type. Matching is
  forgiving: word starts, anywhere in a name, or letters in order (mkm finds "matchkey migration"). Before you type,
  it shows what needs you, what you looked at recently and the common commands. ↩ opens the result (an agent opens
  its project at its column); ⌘↩ opens it in a split.
  Commands carry their shortcuts, and Stop… is shown in red. The menu item is now Project › Search… (⌘K).
• The desktop window has a Needs you reel: every agent waiting on you, across all projects, one column per ask,
  oldest first, each with its thread and its ask (a merge with its files, a question, a usage limit to resume). Open it
  with the Needs you hand (on the window's rail, or in the sidebar's header; its amber count says how many) or View › Needs You. Answering an ask slides its
  column out and the next takes its place; a new ask joins at the end; with none left it says "Nothing needs you.".
  Esc or Back returns to where you were.
• ⌘J (View › Next Ask) steps through the asks one at a time, oldest first, from anywhere: it opens each asking agent
  in its project, or in the Needs you reel focuses the next column.
• A merge's decision in the desktop window says how many files it changes and its line counts ("3 files, +73 −5").
• Desktop: with the sidebar open you can split the pane. ⌘D splits right and ⇧⌘D splits down, opening the next agent in
  the tree beside the one you're looking at. ⌘-click a row in the sidebar, or press ⌘↩ on an agent or project in Search
  ⌘K, to open it in a split. ⌃← and ⌃→ move between panes, and a click in a pane focuses it. ⌘W or a pane's × closes a
  split (with one pane left, ⌘W folds the project as before). Each project keeps its own splits. Rows shown in other
  panes are tinted in the sidebar. A split won't make a pane narrower than 340 pt: at 1440 pt three fit side by side.
• Desktop: expand a pane to the whole window with its arrows-out button or ⇧⌘↩. The sidebar hides, prose reads in a
  centred 800 pt column, code, tables, diffs and tool results get 1060 pt, and an ask sits at the foot at column width
  with its amber ring. Esc or arrows-in brings back exactly the panes you had, each where you left it. Picking another
  agent from ⌘K or ⌘J keeps the pane expanded. Search ⌘K lists Split right, Split down, Close this split, Expand / Collapse
  the pane and Show / Fold the sidebar, with their shortcuts.
• Desktop: project labels in the sidebar show their place icon (This Mac or boxd) for runs that didn't name a place too,
  using the daemon's default place.
• The app now finds the daemon the way the CLI does: CAPCOMD_HARNESS_SOCKET, then $CAPCOMD_HOME/harness.sock, then
  the app's capcomd.socketPath setting, then ~/.capcomd/harness.sock.

Install

Needs Bun ≥ 1.4.0.

bun add -g capcomd@0.12.0
# or from this release's package:
gh release download v0.12.0 --repo MarvinAmador7/capcomd --pattern 'capcomd-0.12.0.tgz' && bun add -g ./capcomd-0.12.0.tgz
capcomd setup

capcomd-0.12.0.tgz.sha256 holds the package's SHA-256. The npm package is published from this workflow run with provenance.

capcomd 0.11.0

Moves capcomd to Rivet 3.1.1. Breaking: runs from before the upgrade are set aside, so finish or cancel them first.

• capcomd now runs on Rivet 3.1.1 (rivetkit 3.1.1, with @rivet-dev/services 0.2.5).
• Breaking: a Rivet 3 engine can't read what the Rivet 2 engine kept, and capcomd doesn't carry it over. On the
  first capcomd serve after upgrading, the old engine data is moved aside to ~/.capcomd/engine/<port>/rivet-v2/
  (nothing is deleted), serve prints one line saying so, and the engine starts empty: runs and agents from before the
  upgrade can't be shown, resumed or cancelled any more, and they leave the run list (kept in
  ~/.capcomd/state/runs-rivet-v2.jsonl; their traces stay). Finish or cancel your runs before you upgrade.
• When you stop capcomd serve (Ctrl+C, SIGTERM, capcomd service stop), it now exits only once its engine and the
  rivet-services it started have stopped.

Install

Needs Bun ≥ 1.4.0.

bun add -g capcomd@0.11.0
# or from this release's package:
gh release download v0.11.0 --repo MarvinAmador7/capcomd --pattern 'capcomd-0.11.0.tgz' && bun add -g ./capcomd-0.11.0.tgz
capcomd setup

capcomd-0.11.0.tgz.sha256 holds the package's SHA-256. The npm package is published from this workflow run with provenance.

capcomd 0.10.1

Fixes capcomd auth login fx on environments built before fx and on Vercel Token Pass teams, and installs from
Homebrew 7.

• capcomd auth login fx works on an environment image built before fx was added: the login installs the pinned fx in
  its VM instead of failing with "fx is not installed in the env snapshot".
• capcomd env build now builds a new image when fx's pinned version changes, instead of keeping the existing image
  that has no fx. The first capcomd env build after updating builds one new image; until then agents keep using the
  current one and install fx as they start.
• A failed capcomd auth login now suggests capcomd doctor instead of pointing at capcomd events <runId>.
• The check after capcomd auth login runs on the agent's configured model (CAPCOMD_AGENT_MODEL or the profile's
  model) instead of the CLI's default. For fx on a Vercel Token Pass, log in with a featured model, for example
  CAPCOMD_AGENT_MODEL=zai/glm-5.3 capcomd auth login fx. When the account won't pay for the model (no AI Gateway
  credit, or a Token Pass that doesn't cover it), the error says the login itself worked and what to change.
• Homebrew 7 and later can refuse to load capcomd "from untrusted tap". Trust the tap once with
  brew trust MarvinAmador7/tap and run the install again (README → Install). The cask now states its macOS
  requirement in the current form (depends_on macos: :sonoma), so Homebrew no longer warns about it.

Install

Needs Bun ≥ 1.4.0.

bun add -g capcomd@0.10.1
# or from this release's package:
gh release download v0.10.1 --repo MarvinAmador7/capcomd --pattern 'capcomd-0.10.1.tgz' && bun add -g ./capcomd-0.10.1.tgz
capcomd setup

capcomd-0.10.1.tgz.sha256 holds the package's SHA-256. The npm package is published from this workflow run with provenance.

capcomd 0.10.0

Everything is a plugin: capcomd now runs on a plugin kernel (sandboxes, agent providers, forges, gates, triggers,
jobs, a watchdog and your own plugins, in process or as separate programs), agent profiles become YAML files you can
share and trust, projects get memory and business knowledge (a reviewed context layer), every working agent gets
background jobs, and fx joins Claude Code and Codex as an agent provider. Several Breaking: changes below. Also
fixes fresh installs of 0.9.0, which could not start runs (an unpinned dependency).

• Fixed: the watchdog no longer flags an agent that started a background job and then waits for it in a command
  (a sleep, a wait on its inbox). The time that command ran alongside the job used up the command time the watchdog
  allows between two signs of progress (plugins.watchdog.stalledAfterMs), so with a short limit the agent was flagged
  stalled soon after the job ended, while it was still waiting. Now the job's time is taken off once, and a command
  still running after the job ends holds the clock like any other.
• A project with no memory yet no longer pays for it in every prompt: when the run's branch has nothing under
  .capcomd/context/ (no lesson, fact or index file; an empty folder or a .gitkeep counts as nothing), agents start
  without the context brief and without the context skills, exactly as if their profile had no context block, and the
  run records plugin.context.skipped with reason empty. Agents can still propose lessons (capcomd result --data '{"context": […]}'); once the first one is approved and lands, the agents after it get the brief and the skills.
  capcomd context brief <profile> says when a profile's agents start with nothing.
• capcomd setup project gives every project the context consolidator. When your project already has a planner that
  can't spawn it (set up before the consolidator existed, or moved from agents.json), setup leaves your planner alone
  and prints the command that lets it (capcomd profiles set planner --set children.allowedChildProfiles=…);
  capcomd profiles migrate prints the same note. Memory changes still wait for your approval before they land.
• Breaking: capcomd run without a planner agent (the built-in placeholder recipe: capcomd run <goal> on a place
  without real machines, --recipe, --legacy, CAPCOMD_RUN_PATH) is off by default. It plans the same generic
  tasks for any goal and judges nothing, so it's kept for comparisons and tests only. Such a run is now refused before
  it starts, with a config error that says so. Use a planner agent instead (--planner <profile>; capcomd setup
  writes one named planner), or turn the placeholder back on with capcomd plugins enable recipe-hierarchical (or
  CAPCOMD_PLUGIN_RECIPE_HIERARCHICAL_ENABLED=true). The same goes for POST /v1/runs without a driver on such a
  place: it answers 422 with that reason. capcomd plugins list shows it as recipe-hierarchical.
• The run list (state/runs.jsonl, or the file CAPCOMD_RUNS_INDEX names for capcomd run new) and each run's
  trace directory are now recorded by capcomd's daemon, as two built-in plugins you can see in capcomd plugins list
  (observe-runs-index, observe-traces). The rows are the same as before, in the same file, except that
  CAPCOMD_RUNS_INDEX must now name a .jsonl file that is a runs index (or doesn't exist yet) and isn't a link:
  for anything else the run is listed in capcomd's own run list instead. A run new that failed partway and is then
  retried with the same --key is now listed once the retry finishes it.
• Plugins that listen to run.changed are now told created once capcomd run new has finished setting the run up,
  not when its record is first made. A run whose run new failed partway is told as created only when a retry
  finishes it.
• The settings and info rows of a place's details screen (GET /v1/sandboxes/{name}) now come from that place's
  sandbox plugin. They read exactly as before.
• Fixed: a docker CLI that hangs no longer hangs capcomd with it. capcomd setup, the run options the apps show and
  starting a run on Docker now say "Docker isn't running" after 3 seconds, even when the CLI (or something it started)
  never lets go.
• New: an agent can start a background job that keeps running after it finishes, such as a server kept up for
  review: capcomd job start --run -- <command> (MCP capcomd_job_start with run: true). It runs in a machine of
  the run's own, made from the run's agent environment the way the checks machine is (no checkout, no credentials,
  package registries only), until the run ends or its --timeout-ms; then it is stopped and the machine deleted.
  The Machines list shows that machine as the run's background jobs. Plugins can start one with
  ctx.jobs.start({kind: "exec", owner: {run: true}, …}), which used to be refused as unsupported.
• Changed: an agent's background job is now stopped once it has run afterTurnMs (30 minutes by default) past the
  agent's last step, not 30 minutes after the job started, so a long build keeps running while its agent is still
  working. A job started with --timeout-ms still stops at that timeout (at most the profile's afterTurnMs).
• For contributors: the context eval has an index-noskills arm (--arms index,index-noskills): agents get the
  same context brief as the index arm, in the same place, without the capcomd-context-doctrine and
  capcomd-context-routing skills, so a run shows what those skills change (success, work, cost, the planted-instruction
  probe, citations). CI runs it on the fake sandbox, where --expect now also checks each agent's delivered prompt:
  the brief in every index arm, the skills in each but this one, and this one's brief the same as index's.
• Breaking: a run you start on a sandbox stays there. capcomd run --sandbox docker (and run new --sandbox, the
  API's sandbox, capcomd_run_new's) now keeps every agent of the run on Docker, even when a profile's
  sandbox.provider names boxd, so a profile can no longer spend your boxd credit on a run you put on Docker. A
  profile's sandbox.provider still wins over a sandbox the run took from your settings (CAPCOMD_SANDBOX, the
  project's or your config). To use a profile's sandbox, start the run without --sandbox.
• Breaking: a project's profile that moves its agents to another sandbox needs your trust first. A file in the
  project's .capcomd/profiles/ that sets sandbox.provider (or the environment or size of a profile that names
  one) is honoured only after capcomd profiles trust <name>, which shows the file and asks, as for the project's
  skills; until then, and again after the file changes, a spawn of it on a run without its own sandbox is refused
  (untrusted). capcomd profiles show says where the profile's agents go and whether the file is trusted,
  validate warns, and the profile lists (capcomd profiles list --json, capcomd_profiles, GET /v1/profiles)
  name the untrusted files in untrustedSandbox. Your own profiles (~/.capcomd/profiles/) need no trust. If you
  use such a project profile, run capcomd profiles trust <name> once, or start the run with --sandbox.
• New: capcomd plugins validate --strict also warns when a plugin could take more of your attention than it needs:
  a notifier (one that listens to every run and agent change) whose config has no quiet option, so people can't turn
  it down short of disabling it. Warnings never fail the check.
• capcomd plugins show <name> now names the commands and MCP tools a plugin adds (by the names capcomd mcp serves
  them, e.g. capcomd_spawn), capcomd plugins list counts them, and both --json outputs (and GET /v1/plugins)
  carry a tools list.
• Faster: capcomd env build (and env build --project) now puts the brains your project maps (capcomd context brain add) into the environment image, each at the commit it is pinned to, so agents start with them instead of
  copying the brain in at every start. Map a brain at a newer commit and the next capcomd env build builds a new image.
  The build says which brains it baked in, and leaves out one that is restricted, can't be read, or has
  credential-shaped text in it (agents then get it at start as before).
• Fixed: only a brain's knowledge folder (knowledge/, or the one you named with --bundle) reaches an agent's
  sandbox now. Before, the whole brain repository was copied in, while only the folder's Markdown files were checked
  for sensitivity: restricted, so a restricted file elsewhere in the repository reached agents. Every file in the
  folder is now checked, Markdown or not (a YAML, JSON, TOML or text file marked sensitivity: restricted or
  sensitivity = restricted refuses the brain, as does any file over 4 MiB or a folder of more than 2000 files: keep
  big attachments outside the knowledge folder). An agent's sandbox also keeps only the brains its own brief cites:
  brains another project's image carries are removed before the agent starts (an agent whose sandbox can't be cleaned
  doesn't start), and checks that capcomd verify runs in a VM never see any brain.
• New: once you open a pull request from a goal branch (capcomd pr open, the app, or capcomd_pr_open), the run
  follows its conversation on GitHub. When someone you allow (triggers.sources.github.allowed in
  ~/.capcomd/config.json) writes there with /capcomd … (or, in mode: "auto", without it), the run's planner starts
  again with their comment in its inbox and pushes more work onto the goal branch, which updates the pull request. In
  the default observe mode a comment without /capcomd is only recorded (capcomd triggers log says the planner would
  have started again); anyone else's comment reaches only the planner's inbox. This works for any trigger source: a
  person's requ...

capcomd 0.9.0

Drivers get much further on their own. A project's runs use its own sandbox, setup registers the project and offers
the Docker env build, and a merge of a verified commit lands in about 2 seconds when the target hasn't moved. Verifies
run side by side, capcomd_await waits on verifies and merges, the orchestration skill opens with team shapes, and a
lead profile lets parts of the work have helpers. Breaking: a goal-branch run you drive yourself becomes ready
only when you mark it done (capcomd goal done, or capcomd_goal with done: true). Checked with a live run before
the release: an Opus driver built a small project with 16 Claude agents on Docker, with no workarounds.

• Fix: verify's reviewer now judges the same code the checks test: your agent's change merged onto the target
  branch. Before, an agent branch cut before the target got code its tests need could fail review even though its
  checks passed. If the target moves during a verify, the review runs again on what the checks tested.

• Fix: capcomd run new --key (and capcomd_run_new) scopes the key to the project, so two projects whose drivers
  pick the same key get separate runs. Runs created before this keep working for their own project.

• Fix: capcomd_setup no longer reports "not ready" because a Codex login is missing when no profile in the project
  uses Codex, or because the plugin is missing when your agent already reaches capcomd's tools. Before a project is
  set up, capacity describes the sandbox your config names.

• Fix: agents' commit subjects, and the pull requests made from them, read like commit messages ("Add X" instead of
  "I added X…"). The title you give an agent with --title is used before the task text, and names like printExpr
  keep their case.

• Fix: capcomd setup's env-image check respects CAPCOMD_WORKDIR. When CAPCOMD_HOME is set, clones default to
  $CAPCOMD_HOME/work.

• Fix: capcomd status <runId> for a run you drive yourself (no planner) shows its agents' state, its budget and
  spend, and its total number of events. With --json, scope includes them, and events counts every event of the
  run.

• capcomd <command> --help (for example capcomd setup project --help) shows that command's usage.

• capcomd run's planner can now hand a part of the goal that splits further to a lead, which splits it among
  helpers and verifies and merges their work itself. New projects get this from capcomd setup. In an existing
  project, add "lead" to the planner's children.allowedChildProfiles in .capcomd/agents.json.

• The orchestration skill now starts with "Choose a team shape": a single loop, a wide fan-out, contract first then
  wide, or leads with helpers. It says which shape fits what you asked for, and has the driver check its plan before
  the first agent starts (the tree, the longest chain of steps, and how many agents can run at once).

• capcomd setup now writes a lead profile, which can spawn up to 3 worker helpers one level down and verifies and
  merges their work itself. Give a part of the work that splits into pieces to a lead, spawned with
  children: {maxChildren: N, maxDepth: 1}. Existing profiles are kept; re-running setup only adds missing ones.

• The reviewer profile that setup writes can now run your project's test runner (bun test, npm test,
  pnpm test, cargo test, …) as well as the check's own commands.

• capcomd_setup and capcomd_run_new say how many agents can run at once in that sandbox (capacity).
  capcomd_profiles and capcomd agents list say what each profile can do and whether it can lead (canLead).

• The capcomd MCP server now gives your agent short instructions as soon as it connects: the team shapes, the skill
  to load, and to start with capcomd_setup.

• Asking a profile that can't spawn (such as worker) to fan out is refused with a message that names the profile
  and what to spawn instead (reason: "cannot_spawn").

• Merging a verified commit is much faster. When the target hasn't moved since the verify, capcomd pushes the verified
  commit as it is, in one round trip, with no second run of the checks. When the target has moved, the checks still
  run again first. Merge results show timings.path (fast or full).

• Verifies of the same target run side by side instead of one at a time, and the reviewer starts alongside the checks
  instead of after them. Set CAPCOMD_REVIEW_PARALLEL=0 to review only after the checks.

• capcomd_await waits on verifies and merges as well as agents (ops: ["vfy-…", "mrg-…"]). With mode: "any", it
  returns as soon as the first one finishes.

• Checking on a verify or merge no longer fails with a conflict. Poll it with capcomd_verify {runId, id} or
  capcomd_merge {runId, id}, or with the same key without resending acceptance; only a parameter you give that
  differs is a conflict. Both tools always answer with the id, and timeoutMs: 0 starts one without waiting.

• Verify and merge results and events include timings (checks, review, queue, fetch, push), so you can see where
  the time went.

• Breaking: if you drive a goal-branch run yourself (no planner agent), it is now ready only when you mark it done,
  with capcomd goal done <runId> --summary "…" or capcomd_goal {runId, done: true, summary}. Before, it became
  ready as soon as its first agent finished, so the apps showed it ready while most of the work was still running.

• A run uses its project's sandbox (from .capcomd/config.json), then the one in your user config, instead of the
  sandbox the engine was started with. You can choose one per run with capcomd run new --sandbox docker|boxd or
  sandbox on capcomd_run_new, and the result says which sandbox the run uses and why. Set a project's sandbox with
  capcomd setup project --sandbox docker|boxd.

• capcomd setup project adds the project to capcomd's project list right away, so your agent's capcomd_projects
  and capcomd_setup see it without a restart. capcomd setup agent --default-project now works without Hermes.

• capcomd setup check and capcomd_setup report the sandbox the project's runs will use and where that setting
  comes from. They also run that sandbox's checks: whether Docker is running or a boxd key is set, the logins, and the
  env image.

• On Docker, setup tells you when the env image has no warm checkout of your repository, or an outdated one, and
  offers to run capcomd env build --sandbox docker (--env-build builds without asking).

• Creating a run with a goal branch no longer clones the repository, so it takes a few seconds instead of about a
  minute. A new run can reuse a goal branch left empty by a cancelled run with the same name; a goal branch with
  commits is never reused or deleted.

• When the checks can't run, for example because the image has no bun, verify says so and tells you how to fix it,
  instead of reporting "tests failed". Verify also installs the project's pinned bun when the image lacks it.

• When capcomd commits an agent's work, the commit message uses the agent's own words (its commit, summary or title),
  not the first line of its task.

• capcomd_runs returns within seconds even when a run is slow to answer, and lists each run's state.

• A cancelled run and its agents show as cancelled everywhere (status, TUI, run list), never as "failed" or "error".

Install

Needs Bun ≥ 1.4.0.

bun add -g capcomd@0.9.0
# or from this release's package:
gh release download v0.9.0 --repo MarvinAmador7/capcomd --pattern 'capcomd-0.9.0.tgz' && bun add -g ./capcomd-0.9.0.tgz
capcomd setup

capcomd-0.9.0.tgz.sha256 holds the package's SHA-256. The npm package is published from this workflow run with provenance.

capcomd 0.8.0

Local mode on Docker is now fast enough to use day to day. Each agent starts from a warm checkout baked into the agent
image instead of cloning, and only as many agents run at once as fit in Docker's memory. Desktop threads also open on
their newest messages. Checked with a live run before the release: three Claude Code agents ran on OrbStack with a Claude
plan login, two at a time, each starting from the warm checkout, and all three pushed their work.

• Desktop app: opening an agent's column shows its newest messages right away, even on very long threads (about
  50 ms instead of up to 20 s on a thread of 6,000 items). Earlier messages load as you scroll up.
• Desktop and menu bar apps: a column stuck on "Couldn't load the thread" while capcomd was unreachable now reloads by
  itself as soon as capcomd is back.
• API: a new route, GET /v1/runs/{runId}/agents/{agentId}/thread/tail (capability agents.thread_tail), returns an
  agent's newest thread items. It also returns cursors to page further back and to continue with live updates.
• Local (Docker): capcomd env build --sandbox docker now keeps a warm checkout of your project in the agent image:
  its full history with the dependencies installed. Each agent starts from it in place instead of cloning and copying
  node_modules. On a repository the size of capcomd, 16 agents get their workspace in about 3 s instead of 18 s,
  and each uses about 1.5 MB of disk instead of about 590 MB. Rebuild it when your target branch moves on or the
  lockfile changes; until then, agents clone as before.
• Local (Docker): capcomd env status and capcomd doctor show how many commits the warm checkout is behind your
  target branch, and whether the lockfile has changed (agents then clone and install their own dependencies). They
  also give the command that rebuilds it.
• Local (Docker): capcomd only runs as many agents at once as fit in Docker's memory. Choose how much memory each
  agent gets with Memory per agent in Local's details: 512 MB, 1 GB (the default), 2 GB or 4 GB. A change applies to
  the next agent that starts, and Agents at once shows the new limit right away. CAPCOMD_DOCKER_AGENT_MEMORY_MB
  still overrides the setting. Agents over the limit wait as pending and start as earlier ones finish. API: the Docker
  sandbox has a new agentMemory setting (appliesTo: new_agents) next to its agentSlots info row.
• Local (Docker): capcomd env build --sandbox docker now moves your Claude Code and Codex plan logins onto the new
  agent image, so their agents get the new CLIs and warm checkout without logging in again. Only the login's own files
  are copied, and the agent image itself never holds a login. If a login can't be moved, it keeps working from its old
  image, and the build says to run capcomd auth login … --sandbox docker.
• Fix: an agent's checkpoints no longer rewrite every unchanged file into git.
• Fix (Local): an agent that was paused, cancelled or failed before its container started no longer holds an
  agents-at-once slot for 10 minutes.

Install

Needs Bun ≥ 1.4.0.

bun add -g capcomd@0.8.0
# or from this release's package:
gh release download v0.8.0 --repo MarvinAmador7/capcomd --pattern 'capcomd-0.8.0.tgz' && bun add -g ./capcomd-0.8.0.tgz
capcomd setup

capcomd-0.8.0.tgz.sha256 holds the package's SHA-256. The npm package is published from this workflow run with provenance.

capcomd 0.7.0

The desktop app (build it with apps/menubar/scripts/build-app.sh --desktop), goal branches (a run's reviewed work
lands on a branch of its own, and you choose at the end whether to open one pull request), and agents that name their
own tabs; also everything in 0.7.0-rc.1. Breaking: capcomd run <goal> now works on a goal branch
(--no-goal-branch for the old behaviour). Checked with a live run on boxd before the release: a planner, two workers
and a reviewer landed a goal on its branch from dev with no approvals, and the pull request into dev opened from it.

• A goal branch's result lists each piece of work by its agent's title, in capcomd goal, the apps' ready card and the
  pull request's description. Work an agent continued from another (say, to fix a merge conflict) is listed once,
  under the agent that carried it on, instead of also showing the first try as "merge failed". API: each landed and
  not-landed entry of GET /v1/runs/{runId}/goal carries title and continues.

• Start a project from the desktop app: + (⇧⌘N) opens a new project column with the folder, the branch the work starts
  from and the goal branch it lands on, the goal, Local or Cloud, the model and its effort, and Start. A folder that
  isn't set up shows its setup steps in place. On Start the column becomes the planner's, and the crew's columns
  appear as it spawns them.

• The desktop app's project menu: click the open project's name for its goal, repos and place, then Message the
  planner (⌘L), Changes, Pause or Resume (⌥⌘P), Stop (asks first), Fold into the title bar (⌘W; a finished project
  offers Remove from the title bar, which lasts until it has news, also across relaunches) and Copy run ID. ⌘K opens a palette of these actions, the other projects, New
  project, Follow and the open project's agents by title. ⌘W folds the open project instead of closing the window.

• Agents name their own tabs. Each agent has a short title (1–4 lowercase words, e.g. "login redirect") that the
  desktop app's crew tabs and column headers, the menu bar's rows, approvals and notifications show instead of id
  fragments. Inside its VM an agent runs capcomd title "<words>"; a planner names its children with spawn --title
  and the run with capcomd title --run. An agent nobody named shows the first words of its task. Naming a tab
  doesn't show up in the agent's thread or activity, and an agent that can't spawn names itself with a small local
  capcomd that makes no extra calls (capcomd reads the name from the agent's own commands).

• Rename an agent yourself by double-clicking its tab or its column header in the desktop app, or with Rename… on
  its row in the menu bar. Your name stays until you clear it (empty the field); the agent's own name shows again
  after that. From your own harness, capcomd title <runId> <agt> <words> and the MCP tool capcomd_title name an
  agent, and capcomd_spawn takes title.

• The desktop app's column header reads "lead · login redirect · waiting on you" (no bot name), and a merge on the
  menu bar's Active card reads "Merge work from into ?".

• API (capability agents.title): agents carry title and titleSource; PUT and DELETE /v1/runs/{runId}/agents/{agentId}/title; new events agent.titled and run.titled; Run.titleSource can be
  agent.

• The desktop app is called capcomd: in the menu bar, its About/Hide/Quit items and the Dock. apps/menubar/scripts/build-app.sh --desktop packages it as capcomd.app (a regular Dock app). Its title bar shows each project by name only, without
  the clock or status line under it.

• A desktop app (CapcomdDesktop, a regular Dock app you can install without the menu bar one): the open project's
  agents as full-height columns that stream their threads live, each with its own message box, and an agent's ask
  docked at its column's foot (Approve ↩ / Deny; Return approves only the focused column's ask, Esc never denies).
  Other projects fold into decks in the title bar (⌘1–9); ⌃1–9 and ⌃←/→ move between agents, and a sideways swipe
  anywhere over the columns moves between them (scrolling up and down stays with the thread under the pointer). A
  merge waits on the agent that asked for it (the lead or planner merging its child's work), so its Approve/Deny
  docks on that agent's column. Follow (on by default,
  ⇧⌘F) scrolls to an agent that asks or fails, and scrolling yourself turns it off. A steer you send settles into the
  thread, and one that failed offers Retry or Discard. The window says when capcomd can't be reached (and reconnects
  by itself), when nothing is running, and when your token was refused.

• Fix: in the menu bar app, a long thread no longer opens on its oldest items and catches up over several seconds; it
  shows once it has been read.

• API: agents have createdAt, when they were spawned (null when unknown; older daemons omit it).

• API: a merge approval's subject.askedBy names the agent that asked for the merge and waits on the decision
  (requestedBy.agentId stays the agent whose work merges); absent for an operator's merge.

• Breaking: capcomd run <goal> with a planner (and every run the apps start) now works on a goal branch of its
  own, capcomd/<goal-slug>, cut from --base (default: the project's target, else the repository's default branch;
  never a guessed main). Its agents' reviewed work lands there with no approval and no pull request per child, even
  when the project merges by pull request. Pass --no-goal-branch to merge into the target as before.

• When the planner is done, capcomd goal <runId> shows the goal branch against its base, what landed (with its
  checks and review), what didn't and why, and the planner's summary. capcomd pr open <runId> opens one pull request
  from it into the base with your gh login (capcomd never merges it); capcomd goal keep <runId> keeps the branch
  without one. capcomd run new --goal-branch G --base B starts a scope on a goal branch; MCP capcomd_run_new takes
  goalBranch and base, and the new MCP tools capcomd_goal and capcomd_pr_open do the same (your agent asks you
  before opening a pull request).

• API (capability runs.goal_branch): POST /v1/runs takes base and goalBranch (a bad one is a 422 naming the
  field); runs carry goalBranch (its branch, base, state and pull request); GET /v1/projects/branches lists a
  checkout's branches for a base menu with a suggested base and goal branch; GET /v1/runs/{runId}/goal is the
  finished branch; POST /v1/runs/{runId}/pull-request and /keep-branch record the choice; new events
  run.goal_completed, run.pr_opened and run.branch_kept.

• As soon as you choose a project folder, the menu bar's composer shows the branch your run's work lands on and the
  branch it starts from: the starting branch is preselected from the project, and when the project doesn't say you
  pick it (never main by default). The branch name follows your goal as you type until you edit it, and a problem
  with either name shows under its field.

• When the planner is done, the desktop app docks a card on the planner's column with its summary, what landed and
  what didn't, and View diff · Keep branch · Open PR; the menu bar shows "Ready: " with the same actions, and
  older runs in its Recent list show a "Ready" or "Stopped" flag while their branch waits on you. Afterwards you see
  the pull request's link, or "Kept on ".

• capcomd notifies you once when a goal-branch run is ready ("Ready: → : 2 of 3 tasks landed") or
  stopped with some work landed ("Stopped: …"); clicking it opens the run. It follows the same Settings switch as
  finished-run notifications.

• When the planner failed or was cancelled, opening a pull request with what landed asks you first: in the apps, in
  capcomd pr open (y/N on a terminal, --yes otherwise) and for agents (capcomd_pr_open with stopped: true).
  The pull request's description then says the run stopped. API: POST /v1/runs/{runId}/pull-request answers 409
  stopped until the body is {"stopped": true}, and GET /v1/runs/{runId}/goal carries the question as
  openPullRequest.confirm.

• Fix: capcomd no longer guesses main as a project's target. GET /v1/projects/inspect sends defaultBranch: null
  when the checkout doesn't say, capcomd setup project suggests origin's real default branch, and running it again
  keeps the target you set instead of resetting it to main.

• Desktop window bench for coding agents (apps/menubar/app/DESKBENCH.md): swift run -c release CapcomdDeskBench
  hosts the desktop window on generated runs (1 to 64 agents, no daemon), drives it (open, project switch, reel steps,
  jumps, swipes, thread bursts, typing, resize, Follow), measures frames, main-thread stretches and which views
  re-rendered, judges the result against the SPEC §1 budgets, and compares builds within the machine's noise (run,
  suite, ab, compare, profile under Instruments, snapshot, explain; --json everywhere, stable exit codes).

• The desktop bench shows where a slow stretch went and what changed between builds: run samples the main thread's
  stack inside long stretches and explain prints each one's top frames (--sampler off to disable; selftest sampler checks it without a window); diff A B compares two time profiles as a call tree in ms per step. Results
  record the exact build (commit, dirty flag) even for a copied binary. ab, compare and run --baseline decide on
  main-thread CPU per step (--objective instructions|frames|latency to change it), with frame metrics as guards and
  late frames measured as ms of lateness per second. profile records the whole scenario, marks its results as
  profiled (never compared: exit 6), and warns that .trace files hold private data and must never be committed.
  The desktop app's views now live in the `Ca...

capcomd 0.7.0-rc.1

Release candidate: agents driven by a durable workflow inside the engine (no process per agent) that ride out a
sandbox provider outage, Rivet 2.3.31 with the engine's data under capcomd's home, and in the menu bar app: bots, run
titles, threads, Settings and the sandbox surface (place details, idle lifetime, Delete for machines left behind).

• The menu bar's Recent list shows each run by its title instead of "Done", with how it ended as an icon by its time
  (merged, done, merge denied, merge failed, failed, stopped; hover it, or ask VoiceOver, for the words). The title is
  the run's label when you (or the agent that started it, through capcomd_run_new) gave it one, else the title of
  the pull request its work merged as, else a short form of the goal ("Add a multiply(a, b) function to
  src/math.ts"), and it changes to the pull request's title once that lands. The goal shows under the title only when
  the title doesn't already say it; hover a cut title for all of it. Active cards and the run view use the same titles.
  The harness API's runs carry it as title and titleSource.
• Fix: a sandbox provider outage of up to 10 minutes (boxd's API not answering, Docker's daemon restarting) no longer
  fails running agents. They wait for their machine and carry on: an agent working in its VM keeps working, and the
  agent shows a "sandbox_outage" notice while it waits, cleared once the provider answers. Calls that are safe to
  repeat (looking up or creating a machine, uploads, renewals, deletes) are tried again with backoff; a command is never
  run twice. An outage longer than that fails the agent with errorKind: "sandbox_unreachable" and retryable: true
  in its result ("the sandbox provider (boxd) didn't answer for 10 min …"), so you can run it again once the provider
  is back. Set CAPCOMD_SANDBOX_OUTAGE_MS where capcomd serve runs to wait longer or shorter. Permanent errors (a
  rejected key, a machine that doesn't exist, a quota) still fail at once.
• Fix: an agent that fails no longer leaves its machine running until its idle lifetime runs out: it is deleted when
  the agent fails. A delete the provider doesn't answer is tried again, with backoff, until the machine is gone.
• Docker not answering ("Cannot connect to the Docker daemon") is now treated as an outage capcomd waits out, as
  above, instead of failing the agent at once.
• Fix: listing runs no longer creates empty runs in the engine. When your run list (state/runs.jsonl) names a run
  this engine doesn't have, for example one a test engine on another port recorded, the menu bar, the harness API and
  capcomd_runs show it as "unknown" with no agents. Before, every listing (twice a second while the menu bar is open)
  quietly created an empty run in the engine for it. Reading such a run's agents, events, thread or approvals no
  longer stalls for seconds either.
• The live end-to-end scripts (scripts/mac-subagents-e2e.sh, scripts/mac-agent-ops-e2e.sh) keep their runs out of
  your run list, so the menu bar no longer shows them. They write their own index in the run's work folder and still
  use your logins, environments, boxd key and settings. To do the same, set CAPCOMD_RUNS_INDEX to a file of your own.
• capcomd serve now opens the harness API only once its actors can answer, waiting at most 30 s. Before, the menu
  bar's first requests after a restart could arrive before the actors were up and fail with warnings in the engine log.
• Fix: a project's settings are looked for from the current folder up to your home folder and no further, even when
  HOME points somewhere else (a test or an agent's scratch home); capcomd's own ~/.capcomd/config.json was read as
  a project's .capcomd/config.json then, so its sandbox and repository settings applied where they shouldn't.
• Agents are now driven by the engine itself: each agent runs as a durable workflow inside capcomd serve instead of a
  separate capcomd agent-drive process per agent. An agent carries on by itself when the engine restarts (nothing has
  to await it to get it going again), a usage-limit pause wakes at its reset from the engine, capcomd await waits
  for change events instead of polling, and a dozen running agents no longer cost a dozen extra processes. The settings
  that change how an agent runs (CAPCOMD_SPAWN_EXEC, scripted agents' CAPCOMD_SCRIPT_*, the agents file) are taken
  from the shell that spawned it, as before. If something goes wrong, start the engine with
  CAPCOMD_AGENT_WORKFLOW=0 to get the old per-agent processes back (this escape hatch is kept for one release);
  set it where capcomd serve (or the background service) runs: every command follows the engine's mode and says so
  if its own setting differs. Design and limits: docs/adr-022-agent-lifecycle-workflow.md.
• capcomd's engine data now lives in capcomd's own folder: ~/.capcomd/engine/<port>/db (or $CAPCOMD_HOME/engine/<port>/db)
  for every port, the default 6420 included, instead of rivetkit's shared ~/.rivetkit, which any other project
  using Rivet on your Mac also writes (a newer one could stamp the database so capcomd's engine refused to start).
  capcomd no longer reads or writes ~/.rivetkit at all; rivetkit's own engine logs go to
  ~/.capcomd/engine/<port>/.rivetkit/. The first time the new version starts on 6420 it copies your existing data
  from ~/.rivetkit/var/engine/db once (it never moves or deletes it: you can remove the old folder yourself once
  you're happy), checks the copy and prints one line saying so; if an engine is still running on the old folder it
  refuses with a sentence saying to stop it first. capcomd also records which engine version last opened its data
  (engine-version.json): before a different version opens it, it copies the database to
  ~/.capcomd/engine/<port>/backups/<old version>-<UTC time>/ (the newest three are kept; restore by putting its
  db/ and engine-version.json back), it refuses to start on data a newer engine already opened, naming both
  versions and the newest backup, and when the engine doesn't come up it prints the engine's own last log lines.
  The engine is Rivet 2.3.31 (from 2.3.27), which keeps scheduled wake-ups (lease expiry, machine reaping, quota
  resets) across engine restarts.
• Menu bar app: Active cards are redesigned. While nothing needs you a card is one line: the agents' faces, who is
  doing what ("worker is editing 2 files") and how long the run has been going. When an approval waits, the card
  opens to the question ("Merge worker's work into main?"), who asked and who is waiting on it, the files it lands with
  lines added and removed, and View diff, Deny and Approve ↩ (Return approves while the card has focus; Esc
  never denies). A failed agent opens the card to the lines that say why, with Open thread and Hide; agents
  stopped at a usage limit say when they pick up again, with Resume now. The chevron shows the agent tree. The
  newest finished run tops the Recent list with how it ended: "Merged into main" (or "Merge denied" when you denied
  it), files and lines, whether its checks passed, and what it cost when API spend was billed. The cards also read in
  light mode.
• Harness API: a merge waiting for approval now says what it would land. approval.requested and snapshot.approvals
  carry subject.files (path, status, lines added and removed; the 20 biggest changes), subject.filesTotal,
  subject.added and subject.removed, read when the merge was parked; snapshot approvals also carry requestedAt.
  An agent's result records how its merge ended (merge: target and merged, failed or denied) and, when its checks
  failed, how (verification.checks.reason) and the lines of the check output that name the failure
  (verification.checks.excerpt). capcomd merge --json of a parked merge includes the same diff.
• Menu bar app: the folder picker (+ › Choose Project Folder…, and Choose… in Settings › Runs) opens in front of
  other apps' windows and keeps the folder you pick; it could open behind the app you were using, and the first click
  in it closed it with no folder. After you pick a folder the menu bar panel opens again on what the folder needs.
• Menu bar app: set a project up right in the composer. Pick a folder with + › Choose Project Folder…: a capcomd
  project is used at once as before; any other folder gets an orange dot on its chip and, in place of the tool row, what
  it needs next. A GitHub checkout shows its repository, the target branch, how changes land (pull requests, or pushes
  when the GitHub CLI isn't logged in, with Log In…), the agents that can work on it, and a spend cap when one of
  them would bill an API key where your runs go; edit any of them in place and press Set Up, or Set Up and Start
  when you've already typed a goal. A folder that isn't a git checkout offers Initialize Git; a checkout with no
  remote offers Publish to GitHub (pick the account or organization, the name and Private / Public; it says first if
  the first commit would include files that look like secrets), then goes straight into the setup. A checkout on
  another host offers Open in Terminal for capcomd setup project, and any folder Choose Another Folder….
  Cancel, the chip's × or Esc go back to the project you had; new runs never move until the folder is set up.
  Needs a capcomd with projects.setup (and projects.git for Initialize Git and publishing); with an older one, a
  picked folder is used as before. Settings › General has a new Keep .capcomd/ out of git switch (off by default):
  projects you set up from the app from then on get .capcomd/ added to their .gitignore.
• Harness API: take a plain folder all the way to a GitHub project from the menu bar app (capability projects.git).
  POST /v1/projects/git-init starts a git repository (git init -b main, no commit...

capcomd 0.6.0

Stable release of 0.6.0-rc.2, with no code changes since it: agents in Docker containers, capcomd tui in the CLI,
and capcomd setup fixes (boxd key, project checkout). See 0.6.0-rc.2 below for the details. The live Mac e2e
(scripts/mac-subagents-e2e.sh) was skipped for this release by owner decision.

Install

Needs Bun ≥ 1.4.0.

bun add -g capcomd@0.6.0
# or from this release's package:
gh release download v0.6.0 --repo MarvinAmador7/capcomd --pattern 'capcomd-0.6.0.tgz' && bun add -g ./capcomd-0.6.0.tgz
capcomd setup

capcomd-0.6.0.tgz.sha256 holds the package's SHA-256. The npm package is published from this workflow run with provenance.

capcomd 0.6.0-rc.2

Release candidate: agents in Docker containers, capcomd tui in the CLI, and capcomd setup fixes (boxd key, project checkout).

• capcomd setup run outside a git checkout (your home directory, say) now asks for the path to your project's
  checkout and offers that repository's origin as the repository, as it does when run inside one. Before, it asked
  for a repository URL with no default and saved the project's settings in the current directory, which from your
  home directory meant capcomd's own config. Without a terminal, it says to run capcomd setup project in the
  repository; it never writes project settings into capcomd's own config.
• capcomd tui [runId] opens the terminal debugger: the run's agents live, a waterfall of what each did, a timeline,
  cost rollups and events (--view picks the first tab). With no runId it opens the latest run. Before, it ran only
  from a git checkout (apps/tui); it now ships with the CLI and the single executable.
• capcomd setup can create its boxd key again: it failed with "org not found" because the boxd CLI rejects
  keys create --org for your active org. Setup now leaves --org out there (the key is fenced to that org anyway);
  for another org it says to boxd auth switch first.
• Running capcomd from inside a boxd machine (an agent like Hermes on boxd) no longer needs a BOXD_API_KEY: when
  the machine has credentials of its own, capcomd setup and preflight say so and use them. An explicit key still
  wins. Agent VMs never get such credentials: capcomd only ever runs agents in isolated VMs, which boxd refuses them
  to, and now refuses to use a VM that isn't isolated.
• capcomd can now run agents in Docker containers on your machine instead of boxd VMs: CAPCOMD_SANDBOX=docker
  (Docker Desktop, OrbStack, Colima or Podman's docker). capcomd env build bakes the agent CLIs into a local image
  and the engine removes expired containers. Differences from boxd: a container instead of a VM, an API key reaches
  the agent in its environment (plan logins are unaffected), and no egress allowlist (a profile that sets egress is
  refused). See docs/providers.md.

Install

Needs Bun ≥ 1.4.0.

bun add -g capcomd@0.6.0-rc.2
# or from this release's package:
gh release download v0.6.0-rc.2 --repo MarvinAmador7/capcomd --pattern 'capcomd-0.6.0-rc.2.tgz' && bun add -g ./capcomd-0.6.0-rc.2.tgz
capcomd setup

capcomd-0.6.0-rc.2.tgz.sha256 holds the package's SHA-256. The npm package is published from this workflow run with provenance.