v0.12.0: Build Receipts: what CSM verified, kept apart from what agents claim

Summary

Every Build Room and AutoFix run now has a Build Receipt: CSM's own record of what it ran and measured, kept apart from what the agents said they did. A check counts as passed only when CSM ran the command on the verified commit and saw it exit 0.

A receipt answers what changed, which commit was tested, what ran and with what result, whether the agents' claims hold up, and whether the branch is still the code that was verified. csm build receipt <id> prints it (--json for scripts), the CSM apps read it from GET /v1/builds/{id}/receipt, and the pull request description CSM prepares now carries a verification table built from it.

Install

Download the archive for your machine, check it against checksums.txt, and put csm on your PATH:

tar -xzf csm_0.12.0_darwin_arm64.tar.gz
install csm_0.12.0_darwin_arm64/csm ~/.local/bin/csm
csm version

Platform	Archive
macOS, Apple silicon	csm_0.12.0_darwin_arm64.tar.gz
macOS, Intel	csm_0.12.0_darwin_amd64.tar.gz
Linux, x86-64	csm_0.12.0_linux_amd64.tar.gz
Linux, ARM64	csm_0.12.0_linux_arm64.tar.gz

The macOS binaries are not signed. If macOS blocks the file after a browser download, run xattr -d com.apple.quarantine ~/.local/bin/csm. Downloads with curl or gh release download are not quarantined. You can also build from source with go install github.com/onoja123/csm/cmd/csm@v0.12.0.

Also in this release

Every check result now records the commit it ran on and whether it timed out, and check output from the AutoFix sandbox is redacted like handoffs are. The version constant reads 0.12.0.

Pull request: #12
Full changelog: v0.11.0...v0.12.0

v0.11.0: Show the logo and your setup when csm runs on its own

Summary

Running csm with no command now shows your setup. In a terminal it prints the logo, the version, and one row each for your active accounts, the switching policy, the local service, Sentry and the working directory. Scripts are unaffected: when stdout isn't a terminal, it still prints the usage text and exits 2.

This is also the first release with prebuilt binaries.

Install

Download the archive for your machine, check it against checksums.txt, and put csm on your PATH:

tar -xzf csm_0.11.0_darwin_arm64.tar.gz
install csm_0.11.0_darwin_arm64/csm ~/.local/bin/csm
csm version

Platform	Archive
macOS, Apple silicon	csm_0.11.0_darwin_arm64.tar.gz
macOS, Intel	csm_0.11.0_darwin_amd64.tar.gz
Linux, x86-64	csm_0.11.0_linux_amd64.tar.gz
Linux, ARM64	csm_0.11.0_linux_arm64.tar.gz

The macOS binaries are not signed. If macOS blocks the file after a browser download, run xattr -d com.apple.quarantine ~/.local/bin/csm. Downloads with curl or gh release download are not quarantined. You can also build from source with go install github.com/onoja123/csm/cmd/csm@v0.11.0.

Also in this release

The version constant now reads 0.11.0, so a plain go build reports the same version as the release.

Pull request: #11
Full changelog: v0.10.0...v0.11.0

v0.10.0: AutoFix: turn Sentry errors into verified, reviewed pull requests

Summary

AutoFix turns an engineering signal into a reviewed pull request, using the same engine as Build Room. The first supported signal is a Sentry error. You connect Sentry once, pick an issue, and CSM takes it from investigation to a verified fix that waits for your approval.

Sentry error → incident (deduplicated) → investigate → reproduce in a sandbox
  → fix in an isolated worktree → verify → independent review → PR you approve

User-facing changes

From the terminal (no Hub, no webhook, no public URL)

cd ~/code/orders-api
csm sentry connect          # paste a token (hidden), pick the org and project, map it to this repo
csm issues                  # unresolved issues with events, users, last seen and CSM's run for each
csm fix ORDERS-API-3F       # run AutoFix on the latest event and follow it live; Ctrl+C detaches
csm build show <id>         # the change, the checks and the review
csm build approve <id>      # push the branch and open the PR (also: finish, retry, cancel, watch)

• Nothing runs until csm fix, so a backlog of issues never turns into a pile of agent runs.
• csm fix starts csm serve in the background if it isn't running. The run lives there and keeps going if you stop following it.
• The token needs only org:read, project:read and event:read. It is typed without echo and stored in ~/.csm/autofix.json (0600). It is sent only to the Sentry host you connected and removed from every agent's environment. --url supports self-hosted and regional Sentry.

For a team, through CSM Hub

• csm hub setup (and AutoFix → Settings → Connect Sentry in CSM Desktop) signs in to the Hub, picks the workspace, project and repository, issues a runner token and shows the webhook URL to paste into a Sentry internal integration. It then sends a signed test delivery.
• csm hub connect <url> --token <t> makes this machine a runner. It leases queued runs for the projects mapped here, runs them, and reports every state and event back. If a lease stops being renewed, the run goes back to the queue.
• csm serve also accepts signed Sentry webhooks directly on POST /v1/signals/sentry.

Limitations

• Sentry is the only signal source so far. The envelope already has a CI evidence type, but nothing feeds it yet.
• Reproduction runs Go and pytest tests.
• Docker shares the host kernel. The sandbox guards against accidents and casual escapes, not a determined attacker with a kernel exploit.
• On macOS, Docker Desktop cannot mount folders under Documents, Desktop or Downloads, so CSM's home must live elsewhere (~/.csm by default works).
• Hub runs execute only on a runner whose user has signed-in agents. Diffs and check output stay on the runner; Hub holds only states and events.

Pull request: #10
Full changelog: v0.9.0...v0.10.0

v0.9.0: Link handoff sessions and commit each agent's Build Room work

Summary

Once a task spans Claude Code and Codex, "which agent wrote this, and why" should still have an answer. Two gaps made it hard: a handoff recorded the session it left but not the one it started, and a Build Room task that moved between agents ended in one commit. This PR closes both.

What changes

• Session links. After the receiving agent's session ends, csm reads its session id the same way it does for a switch and records it as the handoff's target session. With the existing link to the previous handoff, a task can be followed across agents in both directions.

• Per-agent commits in Build Room. Before the next agent starts, csm commits what the outgoing agent left in the task's worktree:

  Work by claude/work before handoff to codex/codex-main
  
  CSM-Agent: claude/work
  CSM-Session: 2f0b1d57-…
  CSM-Handoff: 20261012T145717Z-claude-codex
  CSM-Build: 20261012-145659-908ca2
  

  The task's final commit names the agent that finished it, so git log and git blame show which agent wrote which lines. The handoff record and the task's switch history keep the commit and both session ids.

• Scope. csm commits only in Build Room's own worktrees under ~/.csm/builds; it still never commits in your repository. A test checks both sides.

Pull request: #9
Full changelog: v0.8.0...v0.9.0

v0.8.0: Build Room: plan, build, check, review and prepare a pull request across agents

Summary

csm could run, switch and hand off one agent at a time. Build Room turns one request ("Add team invitations: endpoints, tests and a pull request") into a coordinated run across the agents you have signed in to: a plan you approve, tasks in isolated git worktrees, integration, the repository's own checks, an independent review with a bounded fix round, and a pull request description, with every step recorded. It runs inside csm serve and is driven from the CSM desktop app; csm build list|show read runs from the CLI.

It does not claim correctness. Agent reports are treated as claims, and what csm executed itself (git, checks) is reported separately.

Pull request: #8
Full changelog: v0.7.0...v0.8.0

v0.7.0: Automatic handoff: continue on another agent when every account is limited

Summary

Failover already moves a session to another account of the same agent when it hits a usage limit, and csm handoff can move a task to another agent by hand. This PR connects the two: when a confirmed usage limit leaves no ready account of the running agent, csm saves the task context and hands it to the next agent you chose, on its own, in the same project.

What changes for users

$ csm auto automatic
$ csm auto handoff codex,gemini
Failover: automatic
Hand off to another agent: Codex → Gemini CLI when every account of the running agent is unavailable

• csm auto handoff <agent,...> | off sets the agents to hand off to, in order. It is off by default and only used when the failover policy is automatic.
• Same agent first. Another account of the running agent is still tried first and its native session resumed, exactly as before.
• Then the next agent. csm picks the first listed agent that is installed, has a ready signed-in account and can take an opening instruction, writes the task handoff (context, git state, MCP servers carried over), and starts it in the same project. Unusable agents are skipped, never started.
• Clear on screen: "work reached its usage limit and no other Claude Code account is ready. Automatic handoff: work (Claude Code) → codex-main (Codex)."
• Service and desktop: GET/PUT /v1/failover include handoff_to; an automatic handoff is recorded in the activity log as such.

Pull request: #7
Full changelog: v0.6.0...v0.7.0

v0.6.0: Context checkpoints: save, review, edit and continue a task with any agent

Summary

A handoff used to happen only at the moment of a switch, and whatever csm captured went straight to the next agent. This PR adds context checkpoints: save what an agent is working on at any time, look at what csm captured, correct it, and continue it later with any account of any agent. Every handoff now also records its outcome, so a handoff that did not start, or started in a changed repository, is reported instead of assumed.

What changes for users

$ csm checkpoint
$ csm checkpoint list
$ csm checkpoint show <id>
$ csm checkpoint edit <id> --task "…" --next "…" --notes "…"
$ csm handoff --checkpoint <id> codex-main

• csm checkpoint captures the task in the current project without stopping its agent: task, progress note, files, commands, decisions and next steps from the agent's own session record; root, branch, HEAD, working tree and diff from git; MCP servers by name and status. Without a readable record it saves the repository state only and marks the checkpoint partial.
• Edits are kept separately from what csm extracted, never over it, and the brief says which is which.
• csm handoff --checkpoint <id> continues a checkpoint. A running session picks up the newest checkpoint saved from it, so editing a checkpoint and then switching carries the edits.
• Drift is reported, never "fixed". If the branch, HEAD or working tree changed, or named files are gone, the brief and the opening instruction say so. csm never resets, cleans, stashes or checks anything out to match a checkpoint, and refuses a checkpoint from another repository.
• Outcome per handoff: delivery (opening instruction or file only), whether the agent started and where, and the drift check, settled as complete, partial (with reasons) or failed.
• Service: POST /v1/checkpoints, PATCH /v1/handoffs/{project}/{id}, checkpoint-aware handoff views and activity entries, so the desktop app can save, edit and continue checkpoints through the same code. The provider list also reports whether an agent can resume a session.

Pull request: #6
Full changelog: v0.5.0...v0.6.0

v0.5.0: csm serve: a local service for the desktop app

Summary

The CSM desktop app needs a long-lived process to talk to: something that knows the accounts, starts agents, streams their output and reports what changed. This PR adds csm serve, a local service on a Unix socket in ~/.csm, without moving any rule out of the CLI. Every agent the service starts is a child csm <agent> process in a pseudo-terminal, so switching, failover and handoff behave exactly as they do in a terminal.

What changes for users

$ csm serve --detach
csm service listening on ~/.csm/csm.sock
$ csm serve status
$ csm serve stop

• csm serve runs the service in the foreground; --detach backgrounds it, stop and status manage it.
• HTTP over the socket for accounts and their health, usage refresh, account switch/enable/disable/priority, the failover policy, runs (start, input, resize, output, screen, stop), sessions and resume, handoffs, MCP, approvals, projects, settings and activity.
• Server-sent events (GET /v1/events) for run output, run exits, approvals, activity and section changes, so clients refresh only what changed.
• Approvals from the desktop: under the service, Claude Code shell commands pass through a PreToolUse hook and wait for an allow or deny decision in the app. It can be switched off in settings.
• Network access, opt-in: csm serve --listen HOST:PORT adds a TCP listener that requires a pairing token; csm serve pair prints the address and token. Each run keeps a virtual terminal so a client that cannot render raw bytes can show the screen as text (GET /v1/runs/{id}/screen, run.screen events).

Pull request: #5
Full changelog: v0.4.0...v0.5.0

v0.4.0: Account intelligence: health records, health-aware failover, priorities and a failover policy

Summary

csm already switched accounts on a usage limit, but it always took the next account in the list, knew nothing about why an account had failed before, and showed usage only when you asked. This PR gives every account a provider-neutral health record and makes failover choose the account most likely to keep working, deterministically, while keeping manual switching exactly as it was.

What changes for users

$ csm accounts
Accounts (Claude Code)
────────────────────────────────

  ● work         healthy                  5h 18% · 7d 40%    priority 1
  ○ personal     warning                  5h 84% · 7d 61%    priority 2
  ○ backup       rate_limited until 17:10 unknown            priority 3

Order:
work → personal → backup

• Health per account: healthy, warning (a usage window at or above 80%), rate_limited (in cooldown, or the agent reported rejections within the last hour), authentication_required, unavailable (disabled), unknown (the last run ended with an error that was not a usage limit and nothing has worked since).
• Usage is never estimated. It is shown only when the agent reported it and the window has not reset; otherwise unknown.
• Health-aware failover. Candidates are ranked by health, then fewer failures in the last 24 hours, then your priority. csm auto status prints both your priority order and the order a switch would actually try.
• csm next is unchanged: it follows your priority order exactly.
• Priority is the existing account order, surfaced as priority N and changed with csm account priority <name> <n>, which reorders within one agent without disturbing the others.
• Failover policy: csm auto automatic | manual | disabled | status. on/off remain aliases of automatic/manual. disabled reports the limit and stops; manual reports it and, in a terminal, offers the switch.
• csm account health <name> shows one account in detail: health, status, priority, usage and when it was checked, last used, last success, last failure and its classification, failures in 24 hours, cooldown, profile path, and a one-line next step.

Pull request: #4
Full changelog: v0.3.0...v0.4.0

v0.3.0: Cross-agent handoff: carry the task, not the transcript, between Claude Code, Codex, Gemini CLI and Copilot CLI

Summary

Switching agents used to mean starting from zero: Codex cannot read a Claude Code transcript, and vice versa. This PR adds csm handoff <account> and a provider-neutral task handoff behind it. csm checkpoints the running agent, extracts what matters from its own session records, captures the repository state, prepares MCP for the target profile, writes a compact handoff package, and starts the target agent with an opening instruction that points at it. The new agent reads the handoff, checks the repository, and continues.

It does not fake conversation portability. Between agents the conversation stays behind; the task, the files, the repository state and the MCP verdicts move.

What changes for users

$ csm handoff work-codex
CSM handoff

Current agent                                Claude Code / personal
Target agent                                 Codex / work-codex
Session                                      152f3b1f-039e-4f37-b149-4ef715e3d672
Task context                                 captured at the switch
Git state                                    captured at the switch

Continue with Codex? [Y/n]

In the terminal running the session:

Switching personal (Claude Code) → work-codex (Codex).

  Saving checkpoint                  ✓
  Stopping Claude Code               ✓
  Selecting work-codex               ✓
  Capturing task context             ✓
  Capturing git state                ✓
  Carrying MCP configuration         ✓
  Saving handoff                     ✓
  Handing the task to Codex          ✓
  Starting Codex as work-codex       ✓

Codex cannot read a Claude Code conversation. It starts with a task handoff instead:

    ~/.csm/handoffs/<project>/20261008T110445Z-claude-codex/handoff.md

• csm handoff <account|number> and csm handoff --provider <id>. With a csm session running in the project, that session switches (like csm use), including to another agent, in the same terminal and directory. Without one, the target starts where the command was run, from the last checkpoint.
• Every pair works: Claude ↔ Codex ↔ Gemini CLI ↔ Copilot CLI.
• Same-agent switches (csm next, csm use, automatic failover, recovery) run through the same engine: the native session is still resumed, and the handoff is written as a safety copy with a one-line note.
• csm doctor reports the handoff directory and, per agent, task context extraction and injection support. csm status shows the last handoff.

Pull request: #3
Full changelog: v0.2.0...v0.3.0