# Upgrading ## From 0.10.3 Update as usual with `acc update`. Version 0.10.4 preserves sender permission failures as `transport_permission_denied`, including when access to socket metadata or an expired delivery binding is denied. The CLI prints the original retry key so the same recorded message can be offered again without a duplicate. The refreshed Codex skill uses the client's approved command path for outgoing ACC messages. ACC's existing exact-wrapper rule can authorize those commands. An initial execution refusal records no message; a refused retry preserves an earlier durable message. See [sender permissions](TROUBLESHOOTING.md#i-enabled-live-delivery-but-got-fallback) for the recovery procedure. This release keeps store contract 7 and adds no data migration. The update refreshes installed integrations while preserving their recorded delivery policy. ## Store contract 6 to 7 ACC moves each workspace's store from contract 6 to 7 by itself, right after an update activates a contract-7 runtime. The activation already waits until no client runs older ACC code, so at that point the migration is safe. It builds the message and receipt indexes from validated live records, then replaces the store identity last. Message bytes, receipt bytes, workspace identity and initialization time are preserved. There is no reverse migration: version-6 code refuses a version-7 store. A store that a live older client still holds, or whose migration fails, stays on contract 6. The next ACC command or hook a minute or more later retries it. Until then, coordination is paused in that workspace: Claude Code and Codex show a message about it, other clients write it to stderr, `acc status` names it, and `acc doctor` names the command. To migrate a workspace at once, stop older ACC clients and any program that imports the store directly, then run in that workspace: ```bash acc doctor --migrate-store ``` The command refuses old or unknown live runtime holders, does not install or activate a runtime, contact npm, or restart clients. If it is interrupted, run it again. `doctor --repair` never migrates a store, and hooks never change a store's format. Runtime admission cannot see unmanaged direct library users; stop them before an update. ## From 0.9.x Update as usual: ```bash acc update acc version acc doctor ``` 0.10.0 moves every store from contract 6 to 7, as described above. What you see: - **Activation waits for 0.9.x sessions.** A client session that started under 0.9.x holds contract 6 until it ends. `acc update` downloads 0.10.0 and reports `ACC 0.10.0 is ready; waiting for N active or unidentified process(es)`, and `acc doctor` names them. A session you start while 0.10.0 waits still runs 0.9.x, so activation needs a moment when no such session runs: end or restart them together. - **Stores move by themselves.** Right after 0.10.0 activates, it migrates every workspace's store; you run no command. - **0.9.x and 0.10.0 never share a workspace.** 0.9.x code refuses a contract-7 store. This matters only for a copy of ACC that runs outside the managed runtime, such as an npm-global 0.9.x on another `PATH` or a development checkout: update or stop it. - **Sending a message reads less of the store.** A send and its retries use a bounded index instead of rereading unrelated messages and receipts. 0.10.1 lets this update finish where 0.10.0 could stay pending. A session that ended without naming its client process could leave a native binding that 0.10.0 counted as a live client forever, so `acc update` kept reporting `unknown client pid` holds after every session had closed. 0.10.1 judges such a binding by its session record and removes it while it prepares the update, so the update from 0.9.x finishes once no 0.9.x session runs. From 0.10.0, 0.10.1 keeps the store contract, so it activates without waiting for open sessions. If `acc update` keeps retrying a pending 0.10.0 or 0.10.1 and names processes that are not your clients, or `unknown client pid`, clear the pending release and update again: ```bash acc update --pin none acc update ``` `--pin none` keeps following stable releases and drops a pending release that is not pinned. From 0.10.2, the update does this by itself: a pending release that cannot activate is replaced by a newer one, and a binding whose pid another program now has no longer holds the update. From 0.10.3, a process that has exited but that its parent has not collected (a zombie, `Z` in `ps`) no longer holds it either. ## From 0.8.x Update as usual: ```bash acc update acc version acc doctor ``` The update refreshes every installed integration with its recorded policy. Two of them change a client's own settings: - **Codex.** ACC's permission profile in `~/.codex/config.toml` also allows the Claude Code inbox socket directories, so a Codex session can wake a Claude Code session live. Grants are written in their resolved form, such as `/private/tmp/cc-socks` on macOS. A profile you edited stays yours: doctor then names the missing grants and `acc install --adapter codex`. Start a new Codex session after the update; a session already open keeps its old policy. - **Antigravity CLI.** The install adds `command()` to `permissions.allow` in `~/.gemini/antigravity-cli/settings.json`, and the skill calls the wrapper without quotes, so a woken session runs its ACC commands without an approval prompt. It also adds the command that starts the relay, so the agent starts live delivery without one. Restart `agy`: it reads the file only at startup. `acc uninstall` removes every copy of each rule. `acc doctor` and `acc status` describe an idle session by what a message sent to it meets (`idle, wake on send`, `idle until next turn`, `idle, inbox only`), and each status row carries `processTracked`, `liveDelivery` and `liveLeaseCurrent`. This release adds no store event type or field, so a store it writes stays readable by 0.8.x. The installed version performs the download. If `acc update` from 0.8.2 or earlier fails with `ETARGET` and `No matching version found` right after a release, npm is answering from a package document it cached before the registry listed the release. Run the update so that npm asks the registry again: ```bash npm_config_prefer_online=true acc update ``` From 0.8.3, the download does this itself. 0.8.4 changes what you see around Codex and after an update: - **A new Codex chat is addressable before anyone types in it.** `acc status`, `acc doctor` and the MCP `acc_status` tool register chats that Codex's daemon holds, when ACC's hooks are enabled and trusted in their directory. The chat's first turn continues that session. - **A Codex chat that runs without the daemon says so.** It is told once that live delivery is off; a sender sees the cause beside `no live transport`. After a reboot, doctor advises opening Codex rather than `acc install` when Codex starts its own service. - **A new `CODEX_HOME` on Codex 0.157.1 or newer needs no standalone download.** `acc install` only starts the service; Codex installs its own package. - **One background pass after the update from 0.8.3.** The first client hook or agent command after the update starts the new version's update worker once, even with automatic updates off, to reclaim old runtime generations with the new rule, and records `reclaim.json` in the runtime directory. These run through ACC's own launchers; an `acc` that npm installed globally keeps the entry of the version npm installed, so it does not start this pass. This release adds no store event type or field. 0.8.5 changes what a Codex chat that runs without the daemon is told: - **The launch option that caused it is named.** Codex also runs a chat embedded, even while its daemon runs, when it starts with `-c`/`--config`, `--enable`, `--disable`, `--search`, `-p`/`--profile`, `--oss`, `--strict-config`, `--dangerously-bypass-hook-trust` or `--no-daemon`. The notice, a sender's line and doctor name the option and advise starting Codex without it; put a setting you need in `config.toml` instead. - **You see the notice yourself.** Codex shows it once in the chat as a hook message (`↳ Hook · ACC: …`); the model receives its own line, as before. - **The previous runtime generation goes an hour after the update.** `acc update` runs from the generation it replaces, so it cannot remove that one itself. It records the reclaim as unfinished in `reclaim.json`, and the first ACC command an hour or more later removes the old generation, with automatic updates on or off. This release adds no store event type or field. A sender's delivery JSON may carry `nativeLaunchOption` beside `nativeReasonCode`. 0.9.0 adds Windows and the Antigravity desktop app, and changes what `acc uninstall` removes: - **Windows.** ACC installs and runs natively on Windows 10 and 11, with no WSL, and keeps its state in `%LOCALAPPDATA%\acc`. Live delivery reaches Claude Code through its inbox pipe, Codex through `codex app-server proxy`, and Antigravity CLI through ACC's relay. Codex starts its daemon only from a terminal that is not elevated. On Windows the Antigravity install adds no allow rule, so Antigravity CLI asks before each ACC command. See [Windows](GETTING_STARTED.md#windows). - **The Antigravity desktop app.** Antigravity 2.19.1 or later gets live delivery through the app's own language server, with no relay and no command from the agent. The install adds ACC's grant to `~/.gemini/config/config.json` when the app has created that file. If you open the app for the first time after the update, `acc doctor` asks you to run `acc install --adapter antigravity` once. - **A session's version is the running client's.** `acc doctor` and `acc status` show the version of the client that runs the session, which can differ from the `claude` or `codex` on `PATH`. - **A chat in the Codex app** is reported as `client_session_embedded`. The app runs each window on its own app server, so its chats receive messages at their next turn. - **`acc uninstall` without `--adapter` removes only what this data home installed.** A client that another data home wired is skipped by name. `acc uninstall --adapter ` still removes it. This release adds no store event type or field, and `STORE_VERSION` stays 6. A journalled transaction no longer writes a completion marker: 0.9.0 retires every journal entry that the pointer does not name, and an older ACC's markers leave with their entries. 0.8.x keeps working on a store that 0.9.0 wrote. 0.9.1 changes two things around Codex and Claude Code: - **Codex sessions answer peers without auto-review.** On macOS and Linux the update adds ACC's own Codex rules file, `~/.codex/rules/agents-can-communicate.rules`, so the commands a participant runs need no approval and Codex's auto-review never judges a message to a local peer. ACC's install, uninstall, update and config commands still ask. If a Codex session started before the update still asks, start a new one. See [Codex command approval](CONFIGURATION.md#codex-command-approval). - **Doctor no longer calls the Claude Code plugin edited after an update.** A running session marks the plugin copy it still uses with `.in_use/`; doctor counted that as an edit and advised a reinstall. An install also keeps a copy whose marker names a live process. This release adds no store event type or field, and `STORE_VERSION` stays 6. ## From 0.7.x Claude Code live delivery wakes each session through the inbox socket that Claude Code opens for every session. The research-preview Channels path of 0.7.x is retired. Update as usual: ```bash acc update acc version acc doctor ``` `acc update` and `acc install` retire these 0.7.x parts automatically: - the `claude` shim that 0.7.x put early on `PATH`, and its PATH block in `~/.zshrc` - the Channel entry `acc-channel` in the plugin `.mcp.json`, from every kept plugin copy - the `acc-bootstrap` and `acc-claude-channel` launchers - the bootstrap cache The shim and the `~/.zshrc` block are hash-checked. An edited shim or block is kept, and the command reports it. Remove a kept one by hand when you no longer need it. An old shim that is still on `PATH` launches the plain `claude` command, without `--dangerously-load-development-channels`. Live-delivery consent comes only from the installation record, and upgrading keeps the recorded policy. ACC ignores `ACC_NATIVE_DELIVERY_POLICY`, `ACC_BYPASS` and `ACC_BOOTSTRAP_DEBUG`. For Claude Code, the consent question now says that a session in `bypassPermissions` mode asks before each ACC wake. A Claude Code session that started through the old shim keeps its Channel until it exits. Its next turn binds the inbox. Start new sessions with your ordinary `claude` command. The Claude Code live-delivery minimum is now 2.1.282. With an older Claude Code, live delivery stays off and the recorded policy is kept. Update Claude Code and start a new session: the recorded policy applies to it, with nothing to install again. `acc doctor` reports the state. This release adds no new store event type or field, so a store it writes stays readable by 0.7.x. The Channel captures remain as history in `packages/adapter-claude-code/COMPATIBILITY.md`. ## Recover missing runtime contracts ACC 0.5.5 fixes an upgrade defect that can leave 0.5.3 or 0.5.4 waiting for `acc-claude-channel` processes with `contract unknown`. The 0.4.x updater can activate a newer generation without copying its store contract into the active pointer. Claude Code Channel processes started afterward copy that incomplete pointer even though their runtime declares a contract. For an installation already waiting on an older pending release, run: ```bash npm install -g agents-can-communicate@latest acc update acc version acc doctor ``` The global CLI supplies the new management reader before runtime activation. This step is needed because the older updater retries its pending release before checking npm for another version. If a version pin selects an older release, clear it or select 0.5.5 first. The reader verifies the referenced generation's package identity, complete contents and file modes before recovering a missing contract. Compatible Channel processes can keep running on their original generation during activation. Explicit differing contracts and unknown native bindings still block. A generation without a contract, missing files, or changed contents remains unknown. ACC does not terminate these processes or edit their lease records. ## From 0.4.4, 0.4.3, 0.4.2, 0.4.1 or 0.4.0 This release keeps the existing workspace data format. It changes when an update is allowed to take effect: activation is gated on the store contract a running process declares rather than on which version it happens to be, sessions finish on the generation they started with, unreferenced generation directories are reclaimed, and `acc uninstall` retires the holds its own install published. It carries the previous 0.4.x confirmed service maintenance, outgoing sandbox permissions, delivery diagnostics, session recovery and integration fixes. ```bash acc update acc version acc doctor ``` After publication, `acc version` should report 0.5.0. If a pin keeps an older version, select 0.5.0 or clear it first. A managed update refreshes installed integrations and skills; use the npm instructions below for unmanaged or pre-0.4 installations. Start clients again and complete any hook/trust review they request. With existing live consent, Codex 0.153.4 or newer on macOS arm64 receives local socket permissions when its workspace policy is default or contains only ACC's legacy state root. Custom policies are preserved and reported as unverified. See [outgoing permissions](CONFIGURATION.md#codex-outgoing-permissions). If doctor names a missing local service, follow its prerequisite or explicit install action before opening the new session. A supported explicit install can prepare the service. It does not make a session-bound transport ready. Run `acc doctor` in the project after the new clients have started (or submitted a normal turn). Its per-session lines now explain missing consent, an unidentified client process and a failed or timed-out handshake. `nativeDelivery.sessions[].lastAttempt` in `acc doctor --json` provides the same closed metadata and timestamp. Existing owners may have no attempt record until a new hook runs; missing metadata does not prove hooks are disabled. A previous successful handshake does not prove that the session is reachable now. See [delivery troubleshooting](TROUBLESHOOTING.md#i-enabled-live-delivery-but-got-fallback). Upgrading preserves delivery consent. If doctor reports native delivery off and you want automatic peer requests, use `acc install --adapter codex --delivery actionable` (or the relevant adapter); this can spend model tokens. Codex can save that consent before its local service/session becomes available. Ordinary installation keeps durable inbox access when no verified live channel is bound. Explicit complete setup can prepare a definitely absent supported service. Automatic refresh, delivery off, dry runs, and uninstall do not start or stop that shared service. In Grok, public status supplies the session's own CLI arguments through the next tool hook. Grok still uses explicit inbox reads; this patch adds no external wake or guards. Start clients in a project directory, rather than a home directory containing ACC state. ## What still waits for a process to exit, and what no longer does Earlier releases held a verified update until every live ACC process and every native client binding was gone. Each of those holds now states the store contract it speaks, and only two kinds keep an update pending: - A hold whose declared store contract differs from the incoming version's. This is the case the gate exists for, and a release that changes the store contract still needs every live process to exit. - A hold with no verifiable contract. Older native bindings and generations that predate the declaration remain unknown. A missing field can be recovered when the referenced managed generation declares its contract and passes integrity verification. A hold declaring the same store contract as the incoming version proceeds. Several open Claude Code sessions, a Codex daemon and an idle ACC MCP server no longer have to be closed together to move between releases that share a contract. Processes still running a generation from before the contract field existed must exit once. Close the relevant clients and persistent ACC processes, or accept the eligible Codex service maintenance offer described below. Later compatible runtimes do not require that restart. `acc update` names each remaining hold with its process and its declared contract, so a wait now states its reason rather than only the PID. `acc doctor` reports the same pending notice. A session that is open while an activation completes keeps running the generation it started with, including its hooks, until it ends; it does not get half of one version and half of another. A session whose pin names a generation with a different store contract runs the active generation instead, which is the same behaviour as having no pin. A restart offer for a client's background service is now made only when the version that service is actually running fails that client's captured contract, or when it still holds a native binding. A Codex CLI that updated while its daemon kept serving the previous build is an ordinary state, and it no longer produces a prompt to disconnect open clients. Generation directories that nothing references are removed after an activation instead of accumulating. A directory is kept while any control pointer, live runtime lease, live session pin or in-flight staging hold names it, and an unreadable holder postpones the whole sweep rather than being assumed dead. `acc uninstall` retires the binding records and session pins its own install published, so they stop holding a later activation, when the removal leaves no client installed. It never signals or terminates a client process. Removing one client while another stays installed retires nothing, because a binding record names the generation that published it and no client id. Runtime leases are left in place on purpose: a lease is also what protects the generation a running process is executing from, and clearing it would let that directory be reclaimed out from under the process. A live ACC process therefore keeps holding activation across an uninstall until it exits. ## Confirmed client service maintenance `acc update` can ask once to restart a verified Codex service that holds a native binding blocking activation, or that is serving a version outside the captured native-delivery contract. A serving version that satisfies that contract is left alone, even when the installed CLI has moved to a newer build. The captured maintenance contract uses Codex CLI 0.154.0 and its `pid` backend, with compatible commands and protocol checked again at runtime. The installed CLI and managed executable must already match; ACC does not replace vendor binaries or install an operating-system service. After confirmation, a detached ACC worker waits up to 15 minutes for idle Codex turns, empty queues, the requesting command to exit, and any other ACC process still holding the update. It judges those holds by the same contract rule the activation path uses, so a process declaring the incoming version's store contract does not delay the restart, and one declaring a differing or unknown contract does. It rechecks the approved candidate, settings, PID/start time, executable, socket ownership and versions before stopping the service. It refreshes integrations, starts the service again and verifies the result. If refreshing integrations fails, it still restores the service and reports the incomplete update. A later update worker can resume an already approved recovery without another question. A daemon that its parent leaves as a zombie after the stop counts as stopped, and the worker starts the service again. `acc doctor --json` exposes `update.maintenance`; ordinary `acc doctor` describes its state. A failed or cancelled job is no longer reported once its release is active by another path. A current launcher can use the newer management reader while the old runtime is active. When admission is blocked, doctor returns an update-only report without inspecting the workspace or repairing it. Older launchers gain this reader after activation, or through the one-time launcher bootstrap described below. Open clients disconnect. Resume them afterward and complete any client-owned hook trust review. Codex has no atomic idle-check-and-stop operation: a new turn arriving during the final check can be interrupted. ACC does not promise that client UIs reconnect themselves or that an interrupted turn continues automatically. Unknown ownership, incompatible service layouts and unrelated active processes remain visible blockers. For an unattended command, `acc update --yes` explicitly consents to the same restart. `acc update --check` stays read-only. Background discovery never grants restart consent. Changing the candidate or pin before the stop cancels that approval; idle-wait expiration also leaves the service untouched. Delivery consent and automatic-update opt-outs survive an update even when a native service or feature probe is temporarily unavailable. An old installation can already be stuck with both a pre-0.4.4 pending runtime and the old updater that waits indefinitely. That code cannot discover this fix. Bootstrap the new launcher once with `npm install --global agents-can-communicate@0.5.0`, then run `acc update`. The new launcher stages its verified runtime and retires only an exactly identified obsolete ACC background updater while no integrations are being written. This does not terminate an unrelated client or bypass its lifetime hold. ## From 0.3.1 Upgrade all ACC installations participating in a workspace together, then restart their agent clients. The new runtime reads existing 0.3.1 messages, receipts, decisions, intent, and claims. Installing it does not migrate or clear that history. Mixed running versions are unsupported. Once a new session records an explicit decision replacement or withdrawal, the published 0.3.1 reader rejects its `decisionChange` field. Its doctor can label the valid new record as corrupt. Upgrading the remaining reader restores access; deleting or editing the record is not a remedy. ## Update the runtime and client integrations 1. Finish or pause ongoing work and close the participating clients, including persistent ACC MCP processes. A running process can retain the old code after npm replaces its files. If rollback matters, take a copy of the complete ACC data directory and client settings while those processes are stopped. Keep the copy outside the repository; see [runtime locations](CONFIGURATION.md#override-local-paths-and-identity). 2. Install the released package, then refresh the client integrations: ```bash npm install --global agents-can-communicate@0.5.0 acc version acc install ``` Before publication, use the exact candidate `.tgz` supplied for testing instead of the registry version. `acc version` must report the intended version. If it does not, fix which `acc` your shell resolves before running the installer. 3. Run `acc doctor` from each project you use. Check the runtime and installed bundle diagnostics, and follow any activation instructions from `acc install`. In Codex, check `/plugins`, review and enable/trust the current ACC definitions in `/hooks`, then restart the session. Doctor cannot establish that the client has activated its hooks. In the observed stock Codex 0.153.4 upgrade from 0.3.1 to 0.4, command quoting changed all five ACC hook definitions and required a fresh review of the modified hooks. After that review, a subsequent restart retained all five active. This is activation evidence for that transition, not a promise of trust across arbitrary future upgrades. 4. Resume the intended conversations and confirm peer presence with `acc status`. An unrelated new conversation normally has a new participant id; it does not inherit the previous conversation's addressed inbox. Historical decisions and handoffs remain available through [history reads](CLI.md#historical-recovery). `npm install` alone updates the package but does not refresh the skills and plugin copies inside clients. `acc install` preserves user settings and the recorded delivery policy; it does not turn experimental delivery on for a previously opted-out client. Effective delivery still depends on the current client's capabilities. ## Automatic updates after installation An initial `acc install` turns automatic updates on. Later installs preserve an explicit `acc update --auto off` choice. Full uninstall pauses updates and preserves the setting for the next install. ACC checks for stable releases in an independent background process, normally at most once a day, downloads and verifies a separate runtime copy, and refreshes the installed integrations and skills before switching. The global npm package provides a launcher; the active runtime lives under ACC's data home. Running ACC processes, including idle MCP servers, still publish a hold for as long as they live, and native bindings still hold until observed client SessionEnd cleanup or confirmed process death; the vendor daemon can remain running after that lifecycle event. What changed is which of those holds keeps an update pending: only one whose declared store contract differs from the incoming version's, or that declares none at all. From 0.10.1, a binding that names no client process stops holding when its session record is gone, names an exited process, or, with no process recorded, is offline: closed, or 30 minutes without a heartbeat (#273). For a binding that names its client, `acc finish`, presence TTL, and delivery off still do not prove native end. When a hold does block, close the relevant client sessions and persistent ACC processes to release it, or accept the eligible Codex service maintenance offer in `acc update`. Background updates never request fresh restart consent. Hooks never wait for a network download. If integration refresh temporarily prevents coordination, a hook lets the client continue; its next genuine user turn can restore a missing binding. ```bash acc update # download and apply, or report what is keeping it pending acc update --check # check without installing or changing update settings acc update --auto off # disable background updates acc update --auto on # enable them again acc update --pin 0.5.0 # stay on this exact stable version acc update --pin none # follow stable releases again ``` ACC 0.4.0 lost the previous update setting during a full uninstall. If you already ran that version's `uninstall` and want updates enabled after reinstalling, run `acc update --auto on` once. A later installer cannot distinguish that old uninstall state from an explicit opt-out, so it keeps the recorded `off` value until you change it. `--apply` remains an alias for the plain update command. Pins cannot downgrade an active runtime. `ACC_NO_UPDATE_CHECK=1` disables update networking and background scheduling; manual recovery of an already downloaded update still works. Downloading needs npm, but does not require permission to replace a global installation and never runs package lifecycle scripts. `acc doctor` reports the automatic-update policy and pending notice. A failed download or verification keeps the active runtime. An interrupted integration refresh keeps workspace admission closed until `acc update` finishes the refresh. It does not roll workspace history back. A failed refresh exits with code `4` and reports the adapter and configuration problem to fix before retrying; a verified update waiting for a blocking hold remains pending. A previous runtime version is retained for as long as anything can still reach it — a control pointer, a live ACC process, or an open session pinned to it — so existing launch paths survive the change; once nothing references it, its directory is reclaimed after the next activation instead of accumulating. Client trust is still controlled by the client. Follow any reported activation or hook review steps; copied files do not prove the client has activated them. The initial published-0.3.1 transition above still requires a coordinated restart: old direct binaries and existing embedded core consumers cannot be enrolled retroactively. ## Update scripts and MCP consumers Default CLI/MCP inbox reads and `acc://inbox` now return `{items, nextCursor}` summary pages. They omit bodies and do not mark messages retrieved. Code that expected a full array must list a page, select a message id, then make an exact inbox read to retrieve its body. Follow `nextCursor` until it is `null` when inspecting the whole pending inbox. Exact inbox reads retain the one-item full-message array and receipt transitions. See [CLI inbox](CLI.md#inbox-reply-and-acknowledgement) and [MCP](MCP.md). New decision links remove superseded records from ordinary inbox and automatic attention, while retaining their bodies and original receipts in history. A terminal withdrawal remains visible. These changes do not acknowledge old obligations on the recipient's behalf. Use `acc sync --scope history --type decision --current` to discover the current explicit choices, withdrawals, and conflicts. ## Recovery and rollback An old reader reporting `message.decisionChange is not a known field`, or old doctor reporting an unreadable record immediately after a decision change, needs the new runtime. Run the new `acc version`, refresh integrations, restart clients, and use the new `acc doctor`. If that doctor still reports a fault, inspect its named paths as a separate problem. Do not erase history or use an old repair command to resolve version mismatch. There is no downgrade conversion for new decision records. Reinstalling 0.3.1, including using `acc install --downgrade`, does not make them readable by old clients. A rollback that restores a pre-upgrade data copy necessarily omits subsequent coordination records; retain the newer copy separately. Prefer completing the upgrade so all history remains available.