# CLI Use `acc` to install and diagnose integrations, or to inspect the same communication operations that installed skills use on an agent's behalf. Setup commands are for a person; communication commands are the smaller agent-facing vocabulary. Every command accepts `--json` and `--cwd `. `--workspace ` selects an explicit workspace config where supported by the common boundary. These three global options work before or after the command: `acc --cwd /project status` and `acc status --cwd /project` select the same workspace. A native hook also supplies `--workspace acc://` to select its saved room directly. This reference is local to ACC's data home, is not a network URL, and does not establish session ownership. Ordinary config paths retain their existing validation. ```bash acc help acc version ``` Use `acc --help` (or `-h`) and `acc help ` for that command's required, optional, repeatable and flag options, accepted values, and usage notes. For example, `acc work --help` lists intent modes, and `acc finish --help` lists handoff statuses. `acc config --help` lists its subcommands; `acc config init --help` and `acc help config init` describe initialization. Add `--json` to receive the command description as structured data: `name`, `summary`, `required`, `optional`, `repeated`, `flags`, `subcommands`, `choices`, and `notes`, plus `subcommand` when selected. General `acc help --json` keeps its grouped `commands` result. Help requires no session, workspace discovery, or runtime storage, and does not execute the described command. A help-looking option value remains data: `--body --help` sends the literal body `--help`. ## Coordinate from a session | Command | Required | Optional | |---|---|---| | `acc status` | — | `--session`, `--generation`, `--participant`, `--all` | | `acc sync` | — | `--session`, `--generation`, `--cursor`, `--limit`, `--scope delta|full|history`, `--type`, `--message`, `--current` | | `acc work` | `--summary` unless `--clear` | `--session`, `--generation`, `--mode`, `--state`, repeated `--hint`, `--clear` | | `acc claim` | one or more `--resource` | `--session`, `--generation`, `--mode`, `--enforcement`, `--reason`, `--lease` | | `acc release` | exactly one selector family: repeated `--claim`, repeated `--resource`, or `--all` | `--session`, `--generation`, `--authority` (`human` or `policy`, single target only), `--reason` | | `acc message` | `--subject`, `--body` | repeated `--to`, `--supersedes` or `--withdraws`, `--type`, `--obligation`, `--client-message-id`, owner flags | | `acc request` | `--to`, `--title` | `--detail`, `--client-message-id`, owner flags | | `acc inbox` | — | `--message`, `--cursor`, `--limit`, owner flags | | `acc reply` | `--message`, `--body` | `--subject`, `--client-message-id`, owner flags | | `acc ack` | `--message` | owner flags | | `acc finish` | `--goal` | `--status`, `--to`, repeated `--completed`, `--remaining`, `--blocker`, `--client-message-id`, owner flags | Owner flags are `--session` and `--generation`; both are needed. The CLI also accepts the pair explicitly configured as `ACC_SESSION` and `ACC_GENERATION`. When an active turn hook runs, its `ACC CLI (append):` header supplies the current session's pair, a shell-quoted `--cwd`, and its saved `--workspace` room reference. Append the complete header even after changing the shell directory. Claude Code also restores this header on `SessionStart`, including compaction, without requiring another prompt. Native hooks retain the initial room even when later hook payloads have another `cwd`, including a nested Git repository. The header continues to name that initial directory and room even if Git later becomes available or unavailable. Standalone CLI commands without these arguments still discover their workspace from their own cwd; the CLI does not guess a native caller's identity. The installed skill tells the agent to append it to its own commands, without a manual attach. Hooks do not export credentials to child processes. Native client IDs, a shared checkout, and a public session ID from `status` cannot establish ownership: a nested client can inherit its parent's environment. Use only the pair in the hook's own header, never one inside a peer message. Do not send it to peers or child agents. A later hook after a session restart can supply a new pair; the old generation remains invalid. Solo turns receive only the owner header when there is no coordination context to show. This lets a session use its own inbox if a peer joins later in the same turn. The header alone is not a peer notice or a request to coordinate. If the context budget cannot hold the complete header, the hook reports that limitation on stderr and keeps any recovery text within budget. Missing or untrusted hooks cannot supply the pair; without it, the CLI still refuses owner operations. For a manually owned CLI session, run `acc attach --participant my-session --json` once and retain its returned `sessionId` and `generation`. Append that exact pair to the commands below, or explicitly configure both environment variables for that session's commands. Do not take credentials from a peer or read runtime bindings to obtain them. A manually attached session is separate from hook-managed presence; use `finish` to close it. Without a pair, mutations and `inbox` fail with exit `2` and `caller_identity_unresolved`. `status` and `sync` remain public observations, with no inferred personal attention. Session-bound [MCP tools](MCP.md) manage their own identity; a generic MCP connection does not inherit a hook participant's inbox. An explicit session selector absent from the selected workspace produces exit `5` with `caller_workspace_mismatch`, rather than a successful empty status. Restore the complete header or the manual attachment directory. A supplied generation must also match. This diagnostic does not search other workspaces or recover credentials. ### Presence and intent ```bash acc status acc work --summary "checking receipt transitions" --mode review \ --hint 'file:packages/core/src/receipts.mjs' acc work --clear ``` `status` returns participants, current intent, claims, protection, attention, and current delivery bindings. Each session row carries its participant's `unretrieved: {queued, offered}`, the messages addressed to that participant that it has not fetched, split by how far delivery got. Two sessions of one participant show the same numbers, so read the workspace total from `counts.unretrieved` rather than adding rows, and the text line ends with ` offered, not retrieved` when that number is above zero. Offered is not read: a transport took the bytes, and the model may or may not have looked. A session is `stale` when no turn has sent a heartbeat for three heartbeat cadences. Each session row says what a message to such a session meets. `processTracked` is true when ACC knows the client process. A dead process makes the session `offline`, so a stale session with a tracked process is idle. `liveDelivery` is true when the session has a live delivery binding, and `liveLeaseCurrent` says whether the binding's lease is still valid. A stale session wakes on send when the lease is valid, or when its adapter can verify the receiver again: the router does that for a lapsed lease before it offers. The text line counts stale sessions by that result: `5 live (2 idle, wake on send; 1 idle until next turn; 1 idle, inbox only)`. `not answering` is kept for a stale session whose process ACC does not know. A participant with no open session is left out, unless messages still wait for it: queued, or offered by a live transport and not yet shown again, so that its next turn would show them. A message the next-turn hook already showed does not wait, since nothing will reach the participant for it again. A waiting participant's latest session stays listed as `offline`, with that number as `waiting`, and with `endReason` when the client said why the session ended, such as `"clear"` for Claude Code's `/clear`. The text line names each one: `waiting for a closed session: claude_code-b (cleared, 2)`. `acc status --all` lists every session. Before it reads, `status` registers chats a client already holds but ACC has not seen, so a peer can address a new Codex chat before anyone types in it. Codex's shared app-server daemon lists them; a chat is registered when it is idle, is not a subagent, and ACC's hooks are enabled and trusted in its directory. Its first turn, whether typed or started by a peer's message, continues that session. `acc doctor` and the MCP `acc_status` tool do the same. Default `sync` reads events after a 16-digit event cursor (100 by default, up to 500). `--scope history` discovers historical message headers and reads selected records; `--scope full` adds an unbounded snapshot for explicit workspace forensics. ### Retention A workspace keeps what it is told to keep. `acc prune` reports what it no longer needs and reclaims it only when asked: ```bash acc prune acc prune --apply acc prune --class claims --apply acc prune --before event_cursor ``` **`prune` changes nothing without `--apply`.** The reporting run is the default because this is the one command that takes records out of the store. | Class | Reclaimed when | Threshold | |---|---|---| | `sessions` | presence is `offline` | a confirmed dead pid, or 24 hours without a heartbeat | | `intents` | the session they belong to is reclaimed | - | | `claims` | the lease has expired | leases default to 30 minutes (`--lease-seconds`) | | `participants` | no session of theirs survives and no surviving message names them | - | `--before` takes a 16-digit cursor, the same one `sync` returns, and trims the event log to it. Messages recorded at or below that point go too, but only once nobody is owed them: a receipt that is still `queued`, `offered` or `retrieved` keeps its message, because offered is not read and retrieved is not model attention. A recipient that no longer exists cannot acknowledge anything, and does not hold a message forever. After a trim, `sync` reports `trimmedThrough`. A caller whose cursor precedes it was served a short page and can tell. **An ACC older than this feature cannot**: it will serve the same cursor without reporting the boundary, which is why trimming history is never automatic. Two classes need no operator at all. A retired transaction journal and a superseded retention marker have no reader, so a bounded pass reclaims them once a day when a store is opened, and `acc doctor --repair` reclaims them without that bound. `acc doctor` reports what is still held. ### Claims ```bash acc claim --resource 'file:packages/core/**' --reason "editing receipt logic" acc release --resource 'file:packages/core/**' acc claim --resource 'file:packages/core/**' \ --resource 'file:packages/protocol/**' --reason "updating claim validation" acc release --resource 'file:packages/core/**' \ --resource 'file:packages/protocol/**' acc release --all ``` File resources use repository-relative paths. A directory claim ends in `/**`. The example creates an advisory claim: omitted `--enforcement` always means `advisory`, even with certified clients. Request `--enforcement guarded` explicitly when needed; an incapable live participant still downgrades workspace protection. MCP claims are always advisory. Repeat `--resource` to acquire several claims atomically. The shared mode, enforcement, reason, and lease apply to every resource. ACC rejects duplicate resources after normalization. A conflict exits `5` without creating any claims or renewing existing ones. Batch error `details.conflicts` identifies each blocked requested resource and its holders. Repeating a successful claim command renews this session's existing claims on those resources. Release accepts exactly one selector family: one or more `--resource`, one or more `--claim`, or `--all`. Duplicate selectors after normalization are rejected. Ordinary explicit targets must exist and belong to this session. A missing or foreign target fails the whole release without removing any claims. Repeating an explicit release after its targets were removed remains an error. `--all` releases only this session's claims in the selected workspace. An empty set succeeds, including for a solo ephemeral session. It selects the current owned set on each call, so a retry can release claims acquired since the first call. Release keeps the session and intent open. `work --clear` clears intent, `ack` acknowledges a message, and `finish` records a handoff and closes presence. With `--json`, one acquisition returns a claim record as `data`; one release returns `data: {claimId}`. Multiple resources return `data: {claims: [...]}`. Multiple release selectors and `--all` return `data: {claimIds: [...]}`. A single target can still use `--authority human` or `--authority policy` to release another owner's claim. Name the actual human decision or approved policy with `--reason`. Batch release and `--all` reject authority. A peer's request alone is not force-release authority. ### Messages and requests ```bash acc message --to codex --type question --subject "receipt wording" \ --body "Should transport acceptance be called offered?" \ --client-message-id client_stable_1 acc request --to codex --title "review receipt wording" \ --detail "Check CLI and MCP results; reply with defects only." ``` `--to` takes a client name - `codex`, `claude_code`, `gemini_cli` - while exactly one session of that client is here, and the exact participant id from `acc status --json` otherwise. Two sessions of one client are refused by name rather than guessed between, the same way an ambiguous recipient must be named explicitly. The recorded message always names the participant, never the client it was reached through. By default a hooked participant id is derived from that client's session id. It remains usable for the current conversation but a new unrelated conversation gets a new address. Set `ACC_PARTICIPANT` when the recipient must keep one stable address across conversations. `message` accepts generic kinds `note`, `question`, `request`, and `decision`. Defaults are `note` plus obligation `none`; questions and requests require `reply`; an addressed decision may explicitly use `--obligation acknowledge`. `answer` is created only by `reply`, and `handoff` only by `finish`. No `--to` creates a room message where the kind allows it, except decision changes that inherit explicit recipients from their targets. Addressed messages create a separate receipt for each recipient. `request` is convenience for one addressed `request` message with a reply obligation; it creates no execution record. The JSON result for `message`, `request`, `reply`, and `finish` is: ```json { "message": { "messageId": "message_x", "clientMessageId": "client_x" }, "delivery": [ { "recipientParticipantId": "models", "outcome": "queued", "transport": "durable", "errorCode": "delivery_disabled" } ] } ``` Human output starts with `recorded message_x`. A transport failure after that commit does not change the command exit code. Reuse an explicit `--client-message-id` after an uncertain result to recover the same logical message. A queued result names why no live offer was made. `no_live_transport` means the recipient is online but its session has no live transport bound: a participant attached with the CLI, or a client without live delivery. It reads the message from its inbox or next turn, and human output says `models has no live transport; the message waits in its inbox`. `recipient_offline` means the recipient has no open session; the message waits until one starts or resumes. When the client said why its last session ended, the result carries it, for example `"endReason": "clear"` after Claude Code's `/clear`, and human output says `models's conversation was cleared (/clear); the message waits until that conversation resumes`. `recipient_unavailable` means the recipient's session is open but its live transport could not be reached. The delivery outcome `woken` means ACC woke a Claude Code session through its inbox: ```json { "recipientParticipantId": "models", "outcome": "woken", "transport": "claude-inbox" } ``` Human output prints it as `woke models via claude-inbox; the message arrives with its next turn`. The wake carries only fixed ACC text and the message id. The receipt stays `queued`. The session's next-turn hook then shows the body and records the receipt as `offered` via `next-turn`. A Claude Code session that bypasses permission prompts holds each wake for its user's approval, unless its `crossSessionInbound` setting is `accept`. The outcome then carries `"pendingApproval": true`, and human output says `sent a wake to models via claude-inbox, which its session holds for approval because it bypasses permission prompts; the message arrives with its next turn`. A session whose `crossSessionInbound` is `refuse` gets no wake: the message stays `queued` with `delivery_disabled`. `reply` additionally returns `receipt`: the original message id, the replying participant, and state `acknowledged`. Its `message` and `delivery` describe the outgoing answer. Human output distinguishes `recorded ` from `acknowledged `. ### Inbox, reply, and acknowledgement ```bash acc inbox acc inbox --message message_x acc reply --message message_x --body "Yes. Use offered." acc ack --message message_y ``` Without `--message`, inbox returns `{items, nextCursor}`. Each item has a `message` summary and its `receipt`; listing never returns bodies or changes receipts. Summaries include the complete message/thread/sender ids, kind, obligation, timestamp, reply link, subject (up to 160 UTF-8 bytes), `bodyBytes`, `artifactCount`, and untrusted attribution. Bodies, artifact details, handoff payloads, and recipient lists require an exact read. Pages are newest first (descending message id breaks timestamp ties), default to 20 items, and contain at most 12,000 bytes of formatted page JSON, excluding the CLI envelope. `--limit` accepts 1..500 but cannot raise the byte ceiling. Continue with `acc inbox --cursor ` until it is `null`. The cursor is a complete message id, not an offset; reading or acknowledging it does not shift the next page. These are live pages: omit the cursor to see new arrivals. An unknown or foreign cursor is an error. `--message ` returns the existing one-item array with the complete message/receipt pair, advancing that participant's receipt to `retrieved` when needed. It cannot be combined with `--cursor` or `--limit`. An exact id also reads an acknowledged message, preserving its receipt, timestamp, and event history. Use the original message id to inspect acknowledgement; the outgoing reply belongs to its recipient's inbox. Resolved messages stay out of the ordinary inbox. Reply creates an `answer` in the same thread and acknowledges the original atomically. `ack` acknowledges without writing an answer and has no state override. For an unanswered question or request, it exits `5` without changing the receipt: use `reply` to answer, clarify, or decline. An already acknowledged receipt remains an idempotent no-op. You can `reply` after `ack` or an earlier answer without changing the original receipt timestamp. Use a new `--client-message-id` for a distinct reply, and the same key and content for a retry. Acknowledgement is not acceptance of work; an acceptance reply names the scope and next step, while a later result reports what was actually verified. ### Historical recovery ```bash acc sync --scope history --type handoff --json acc sync --scope history --type handoff --cursor message_x --json acc sync --scope history --message message_y --json ``` History returns `{scope: "history", view: "summary", items, nextCursor}` with the same summary fields, ordering, page limits, and message-id cursors as inbox. `--type` accepts any message kind and filters before pagination; keep the same filter between pages. This public workspace observation includes records from before your session joined. Exact history reads return `view: "message"` and one complete message in `items`, without changing any receipt, plus `receipts`: one entry per recipient with `state`, `updatedAt` (the last state change) and `offer` - the transport that accepted it, when, and `repeatedAt` if the next turn showed it again - or `offer: null` when no offer was recorded or an older ACC recorded it. This is how a sender tells a message a peer's client accepted (`offered`) from one its participant fetched (`retrieved`) or answered (`acknowledged`). Retrieved is not model attention either. Do not combine `--message` with type, cursor, or limit; message and type are valid only in history scope. Decision reads also include `decisionStatus`. Use `acc sync --scope history --type decision --current --json` for terminal decisions and withdrawals; keep these filters when paging. Exact reads cannot use `--current`. `current` means no explicit successor, not truth or consensus. To change a decision, send another `acc message --type decision` with repeated `--supersedes ` or `--withdraws ` (1..16 unique IDs; exclusive). Use subject/body for the new position or withdrawal reason. Changes inherit the target recipients and authors, including offline participants; `--to` adds recipients. Any owned participant can record an attributed change. Multiple successor branches remain conflicted until a new change explicitly references all current alternatives. Old records leave ordinary inbox/automatic attention without any receipt change; exact inbox and history still recover them. See [decision lifecycle](PROTOCOL.md#decision-lifecycle). ### Handoff ```bash acc finish --goal "document receipt semantics" --status partial \ --completed "protocol updated" --remaining "acceptance proof" \ --blocker "packed test not run" --to codex ``` Status is `complete`, `partial`, or `blocked`. `finish` records a structured handoff, releases the caller's claims, and ends ACC presence for that session. It never closes the external AI client. An addressed handoff requires acknowledgement; a room handoff does not. Use `complete` when the original goal is done; `partial` does not instruct the peer to continue. Distinguish authorized next steps from excluded backlog. If agreement is needed before leaving, request the concrete continuation and obtain a substantive reply before `finish`; a reply sent after `finish` may wait durably for the sender to return. ## Install, diagnose, and update | Command | Flags | |---|---| | `acc install` | `--adapter`, `--home`, `--delivery off|actionable|all`, `--indicator on|off`, `--dry-run`, `--downgrade` | | `acc uninstall` | `--adapter`, `--home`, `--dry-run` | | `acc doctor` | `--home`, `--repair`, `--migrate-store` | | `acc config init` | `--yes`, `--force` | | `acc config validate` | — | | `acc update` | `--check`, `--auto on\|off`, `--pin VERSION\|none`, `--yes`, `--apply` (alias) | | `acc help` | — | | `acc version` | — | `acc uninstall` takes back what the current ACC data home installed. A client on the machine that this data home has no install record for - one another data home wired, such as your own beside an isolated `ACC_DATA_HOME` - is skipped with the reason; name it with `--adapter` to remove its ACC wiring anyway. `--delivery off|actionable|all` is a per-client recipient policy request, not a capability switch, and the default is `off`. `--adapter` is repeatable to name several clients. An explicit `--delivery` applies uniformly and never prompts; omitting it on an interactive terminal asks one default-No question for all selected clients that need a decision. Codex can save consent while its local service is unavailable or has no loaded session; this does not activate delivery. A non-interactive run or a `--dry-run` keeps fresh clients off. A recorded opt-in is kept on upgrade. If the detected client cannot receive native delivery - unsupported, below the captured minimum, a prerelease, known-bad, or a wrong platform - installation keeps the effective policy off and prints the reason. Every adapter reads live-delivery consent from the installation record. Claude Code live delivery uses the inbox that each Claude Code session opens itself. ACC adds no launch argument, shell file or wrapper for it. Codex LocalDaemon delivery also keeps ordinary launch arguments unchanged. `acc install --adapter --delivery off` disables new native offers for that client. On a supported explicit install, complete consent can prepare a missing Codex service. On macOS arm64 with Codex 0.154.0 or newer, the same choice includes downloading a missing standalone package from OpenAI. ACC selects the installed CLI version and verifies the official installer's pinned checksum. The installer uses the selected `HOME` and `CODEX_HOME`. Your existing npm or Homebrew command and shell profiles remain unchanged. An older consent that covered service start receives one expanded choice for the download. An accepted or declined answer persists. To change a declined answer, use `acc install --adapter codex --delivery actionable` (or `all` for that policy). Installing the Antigravity adapter always adds one prefix rule for ACC's wrapper to `~/.gemini/antigravity-cli/settings.json`, so ACC's commands run there without an approval prompt; nothing asks about it and the delivery policy does not change it. Uninstall removes exactly that rule. See [Antigravity CLI command approval](CONFIGURATION.md#antigravity-cli-command-approval). Explicit `--delivery actionable|all` also approves a required download on supported clients. Dry runs, delivery off, doctor, automatic refresh, and message delivery do not download Codex or start its service. Uninstall does not remove Codex or stop the shared vendor daemon. The install summary names each client's requested policy, activation state and verified fallback. `doctor` separates protocol readiness, recorded consent and a live channel in the current workspace, with a next step for missing activation. A supported version or an installed plugin alone is not an active delivery channel. `runtime: active` means ACC has a reachable local transport binding. Claude Code applies its own inbound controls to each wake: a session in `bypassPermissions` mode holds the wake for approval. See [delivery troubleshooting](TROUBLESHOOTING.md#a-claude-code-session-holds-or-drops-acc-wakes). In doctor JSON, `nativeDelivery.activation` distinguishes missing launch setup from a recorded setup (or `not_required` for a pre-existing service). `policy` is the installed choice. `deliveryDecision` gives its known source and reports legacy provenance as unknown. `nativeServiceSetup` reports service infrastructure separately. `sessionPolicy` describes a native binding when one is visible. Every adapter rereads the current recorded consent at hooks and before new offers. `nativeDelivery.sessions` lists each current session's identity, present transport state and `lastAttempt`: timestamp, startup/turn event, effective policy and its source, whether that policy was missing/invalid/off, whether a client process was identified, and the closed handshake result/reason. `lastAttempt: null` means no usable attempt was observed for this generation; it does not prove hooks are disabled. A past successful handshake is separate from current transport reachability. ACC replaces this small diagnostic beside the hook-owner file outside the repository; it never adds attempt history to agent context. See [delivery consent](CONFIGURATION.md#keep-delivery-consent-user-owned). An initial `acc install` enables automatic updates. Reinstalling preserves an explicit `acc update --auto off` choice. A full uninstall pauses updates; reinstalling restores the remembered setting. A background worker checks stable releases at most once a day, downloads and verifies a separate runtime, then refreshes installed integrations and skills once no hold blocks. A runtime lease or native binding blocks only while the store contract it declares differs from the incoming version's, or while it declares none; records written before 0.5.0 declare none, so the first update after upgrading still waits for them. ACC leases end on confirmed process exit; a native binding can clear on observed SessionEnd even while its vendor daemon remains alive, or on confirmed process death. Unknown PIDs remain holds. `finish`, presence TTL, and delivery off are not observed native end. Hooks do not wait for network work. `ACC_NO_UPDATE_CHECK=1` disables update networking and background scheduling. `acc update` requests the update immediately. If a verified Codex service holds a native binding that blocks activation, or serves a version its captured native-delivery contract refuses, it asks once to restart that service. After confirmation, a detached worker waits for idle work and for any ACC process whose declared store contract still holds the update, refreshes integrations, restarts the service and verifies the result. Open clients disconnect; use `acc doctor` for progress and resume the clients afterward. `--yes` supplies explicit noninteractive restart consent. Without consent, or with unknown ownership, the update remains pending. See [maintenance limits and recovery](UPGRADING.md#confirmed-client-service-maintenance). `--check` only checks and cannot be combined with settings changes. `--auto off` disables background updates, and `--auto on` enables them. `--pin 0.4.0` holds an exact stable version; `--pin none` follows stable releases. A pin cannot downgrade the active runtime. The old `--apply` flag remains accepted. Failed downloads keep the working runtime. A failed integration refresh exits with code `4`, names the failed adapter and configuration error, and keeps workspace admission closed. Fix the reported configuration problem, then run `acc update` to finish it. `acc doctor` reports the update policy and pending notice. During blocked activation, a current launcher returns `scope: update` and `workspaceInspection: unavailable_during_update` without opening workspace state; `doctor --repair` remains blocked. Native clients may still require hook trust or activation review. See [Upgrading](UPGRADING.md) for the initial 0.3.1 transition and recovery details. `acc doctor --migrate-store` explicitly migrates the selected workspace from store contract 6 to 7. Stop old ACC clients and any direct library callers first. The command fences runtime admission and refuses live holders with an old or unknown contract. It preserves primary records, prepares the message indexes, then changes the durable identity last. It neither installs a release nor restarts clients. `--repair` is a separate operation and never changes the store contract; the two flags cannot be combined. Hooks leave a version-6 identity unchanged and fail open with the migration remedy. Doctor JSON includes bounded `indexDiagnostics`; a cache failure after recording a message remains send success and is reported separately. ## Integrate a client lifecycle `acc attach --participant `, `acc heartbeat --session --generation `, and `acc detach --session --generation ` are public executable boundaries used by adapters. Installed skills do not teach models to call them. They maintain ACC presence; they do not start, keep alive, or close the external client process. ## Exit codes | Code | Meaning | |---|---| | `0` | success | | `2` | usage | | `3` | timeout | | `4` | data or incompatible state | | `5` | claim or generation conflict | | `6` | attention | Next: [Protocol](PROTOCOL.md) · [MCP](MCP.md) · [Configuration](CONFIGURATION.md)