agents-can-communicate 0.10.4 → 0.11.1

package/README.md

@@ -3,9 +3,11 @@
 **The message your clients can’t send each other.**
 
 Claude Code can message your other Claude Code sessions, and Codex can queue a message for
-another Codex session. Neither client offers a way to message the other’s sessions. ACC
-carries questions, reviews and handoffs between sessions in different vendors’ clients, on
-your machine.
+another Codex session. From Claude Code, OpenAI’s Codex plugin can ask Codex for a review,
+hand it a task or move the conversation into Codex; it runs Codex under Claude Code, in that
+direction only. Neither client offers a way to message a session you opened yourself in the
+other one. ACC carries questions, reviews and handoffs between those sessions, in either
+direction, on your machine.
 
 You open each client normally and choose its work. Every session keeps its own model,
 conversation, and permissions. Coordination runs locally, with no lead agent managing the
@@ -45,16 +47,17 @@ flowchart TB
 
 ## When ACC helps
 
-- **Get a second opinion from another vendor’s model.** Ask a Codex session to review a change
-  your Claude Code session just made, and send its findings back to the session that wrote the
-  code.
-- **Bring parallel features together.** Let sessions in different clients ask each other about
-  a shared API before they build around different assumptions.
+- **Run parallel work across clients.** Start each task in whichever client has limit left,
+  and let the sessions see who is working on what, ask each other about a shared API, and
+  agree who takes which issue before they build around different assumptions.
+- **Get a second opinion from another vendor’s model, in either direction.** Ask a Codex
+  session you already have open to review a change your Claude Code session just made, and
+  send its findings back to the session that wrote the code; or let Codex ask Claude Code.
 - **Switch clients mid-feature.** When a limit approaches or another model suits the work
-  better, leave a handoff with decisions and unfinished work for a session in the client you
-  open next.
+  better, leave a handoff with decisions, unfinished work and what was verified, rather than a
+  transcript, for a session in the client you open next.
 
-## Try one review across clients
+## Try one feature across two clients
 
 You’ll need **macOS, Linux or Windows 10/11, Node.js 24 or newer**, and supported coding
 clients on the same machine and operating-system user. On Windows, ACC runs natively, with no
@@ -70,24 +73,29 @@ The installer connects supported clients it finds. Follow its activation instruc
 any required hook or plugin trust, then restart your clients from the project directory. The
 [setup guide](docs/GETTING_STARTED.md) covers client-specific steps.
 
-Open Claude Code and Codex in the same project. After Claude Code has changed something, for
-example an account-registration form, ask it:
+Open Claude Code and Codex in the same project and give each one its own part of one feature.
+Ask Codex:
 
 ```text
-Ask the Codex session in ACC to review the registration form change
-you just made. Name the files and what it should check.
+Add an account-registration endpoint.
 ```
 
-Then ask Codex:
+And ask Claude Code:
 
 ```text
-Answer the review request in ACC. Read the files it names, check
-what it asks, and reply with what you found.
+Build the account-registration screen.
 ```
 
-Codex should find the request without you pasting it, and Claude Code should see the findings
-at its next turn without you copying them back. The sender can check whether its message was
-delivered and answered.
+Those are the whole prompts. Each session sees that the other is present and what it is
+working on. When the screen needs the endpoint’s request and response shape, the Claude Code
+session can ask the Codex session and get the answer at its next turn, without you carrying
+it across; the sender can check whether its question was delivered and answered. The agents
+decide when to coordinate; ACC does not guarantee they will notice every dependency.
+
+The same channel carries a review: ask the session that made a change to request a review
+from the other session in ACC, naming the files, and ask the other to answer it. The
+[setup guide](docs/GETTING_STARTED.md#2-open-two-sessions-and-give-them-ordinary-tasks)
+walks through both.
 
 ## Client support
 

package/bin/acc-indicator.mjs

@@ -0,0 +1,5 @@
+#!/usr/bin/env node
+// Deliberately outside runEntry: observation must not acquire a runtime lease,
+// schedule updates or open/recover the coordination store.
+import { runIndicator } from "@agents-can-communicate/cli/indicator";
+await runIndicator();

package/bin/entrypoints/acc-antigravity-relay.mjs

@@ -11,11 +11,11 @@ import { createRelay } from "@agents-can-communicate/adapter-antigravity/relay";
 import { listRegistrations, newRelayId, relayDir } from "@agents-can-communicate/adapter-antigravity/relay-endpoint";
 import { findConversation, spawnRelay, startRelay } from "@agents-can-communicate/adapter-antigravity/relay-start";
 import { loadSessionBinding, readProcessArgs } from "@agents-can-communicate/adapter-sdk";
-import { platformDataHome } from "@agents-can-communicate/cli";
+import { platformDataHome } from "@agents-can-communicate/cli/runtime-paths";
 import { createCoordinationService } from "@agents-can-communicate/core";
 import { resolveClientPid } from "@agents-can-communicate/hook-runner/client-pid";
 import { readProcessTable } from "@agents-can-communicate/hook-runner/process-table";
-import { readInstalledLivePolicy } from "@agents-can-communicate/installer";
+import { readInstalledLivePolicy } from "@agents-can-communicate/installer/live-policy";
 import { createId } from "@agents-can-communicate/protocol";
 import { openFilesystemStore } from "@agents-can-communicate/storage-filesystem";
 

package/bin/entrypoints/acc-hook.mjs

@@ -12,33 +12,13 @@ import { createId } from "@agents-can-communicate/protocol";
 import { runHook } from "@agents-can-communicate/hook-runner";
 import { hookEntrypointFor, resolvePinnedGeneration }
   from "@agents-can-communicate/cli/hook-support";
+import { loadAdapters } from "@agents-can-communicate/cli/adapters";
 
 // A hook runs one client's adapter, and loads only that one: every other
 // adapter was a set of modules loaded on each turn and never run, about a
-// millisecond each on windows-latest.
-const ADAPTERS = {
-  // Registered like any other client. Its hook commands carry an extra
-  // argument - the event name - because this client's payload has none.
-  antigravity: () => import("@agents-can-communicate/adapter-antigravity")
-    .then(module => module.createAntigravityAdapter()),
-  claude_code: () => import("@agents-can-communicate/adapter-claude-code")
-    .then(module => module.createClaudeCodeAdapter()),
-  codex: () => import("@agents-can-communicate/adapter-codex")
-    .then(module => module.createCodexAdapter()),
-  gemini_cli: () => import("@agents-can-communicate/adapter-gemini-cli")
-    .then(module => module.createGeminiCliAdapter()),
-  grok: () => import("@agents-can-communicate/adapter-grok")
-    .then(module => module.createGrokAdapter()),
-  kimi: () => import("@agents-can-communicate/adapter-kimi")
-    .then(module => module.createKimiAdapter()),
-};
-
-// The adapters this hook can use: its own, or none for an id nobody registered,
-// which runHook answers the way it always has.
-async function adaptersFor(adapterId) {
-  if (!Object.hasOwn(ADAPTERS, adapterId)) return {};
-  return { [adapterId]: await ADAPTERS[adapterId]() };
-}
+// millisecond each on windows-latest. An id nobody registered gets none, which
+// runHook answers the way it always has.
+const adaptersFor = adapterId => loadAdapters([adapterId]);
 
 const readStdin = () => new Promise(resolve => {
   // A hook is always given its payload on stdin, but a client that closes it

package/bin/entrypoints/acc-mcp.mjs

@@ -3,12 +3,14 @@ import { randomBytes } from "node:crypto";
 
 import { EXIT, createId } from "@agents-can-communicate/protocol";
 import { createCoordinationService } from "@agents-can-communicate/core";
-import { readInstalledLivePolicy } from "@agents-can-communicate/installer";
+import { readInstalledLivePolicy } from "@agents-can-communicate/installer/live-policy";
 import { createDeliveryRouter } from "@agents-can-communicate/delivery-router";
 import { registerDiscoveredSessions } from "@agents-can-communicate/hook-runner";
 import { openFilesystemStore } from "@agents-can-communicate/storage-filesystem";
-import { ALL_ADAPTERS, createGitProbe, discoverWorkspace, platformDataHome, runtimePaths }
-  from "@agents-can-communicate/cli";
+import { loadAdapter, loadAdapters } from "@agents-can-communicate/cli/adapters";
+import { createGitProbe } from "@agents-can-communicate/cli/git-probe";
+import { platformDataHome, runtimePaths } from "@agents-can-communicate/cli/runtime-paths";
+import { discoverWorkspace } from "@agents-can-communicate/cli/workspace-discovery";
 import { serve } from "@agents-can-communicate/mcp-server";
 
 export async function main({ managerRoot = null, packageRoot } = {}) {
@@ -46,7 +48,6 @@ const paths = runtimePaths({
 const store = await openFilesystemStore({ root: paths.root, clock, ids,
   workspaceId: descriptor.id });
 const service = createCoordinationService({ store, clock, ids });
-const adapters = Object.fromEntries(ALL_ADAPTERS().map(adapter => [adapter.id, adapter]));
 
 await serve({
   input: process.stdin,
@@ -54,14 +55,15 @@ await serve({
   log: message => process.stderr.write(`acc-mcp: ${message}\n`),
   context: {
     service,
-    deliveryRouter: createDeliveryRouter({ service, adapters, clock,
+    // Each recipient's adapter loads with the first message routed to it (#270).
+    deliveryRouter: createDeliveryRouter({ service, loadAdapter, clock,
       readLivePolicy: ({ adapter }) => readInstalledLivePolicy({ dataHome,
         adapterId: adapter.id }) }),
     workspaceId: descriptor.id,
     participantId,
     descriptor,
     runtimeDir: paths.root,
-    registerNativeSessions: () => registerDiscoveredSessions({ adapters,
+    registerNativeSessions: () => registerDiscoveredSessions({ loadAdapters,
       workspaceId: descriptor.id, dataHome, env: process.env }),
   },
 });

package/bin/entrypoints/acc.mjs

@@ -3,13 +3,26 @@ import { randomBytes } from "node:crypto";
 import { readFile } from "node:fs/promises";
 
 import { createId } from "@agents-can-communicate/protocol";
-import { readInstalledLivePolicy } from "@agents-can-communicate/installer";
-import { createDeliveryRouter } from "@agents-can-communicate/delivery-router";
-import { registerDiscoveredSessions } from "@agents-can-communicate/hook-runner";
-import { ALL_ADAPTERS, askConfirmation, main as runCli } from "@agents-can-communicate/cli";
+import { loadAdapter, loadAdapters } from "@agents-can-communicate/cli/adapters";
+import { askConfirmation } from "@agents-can-communicate/cli/confirm";
+import { main as runCli } from "@agents-can-communicate/cli/main";
+
+// A command loads what it uses: `acc version` no client adapter, store or
+// router, and a message only its recipients' adapters (#270).
+const lazyRouter = ({ service, clock, dataHome }) => {
+  let router;
+  return { offer: async message => {
+    router ??= Promise.all([import("@agents-can-communicate/delivery-router"),
+      import("@agents-can-communicate/installer/live-policy")])
+      .then(([{ createDeliveryRouter }, { readInstalledLivePolicy }]) =>
+        createDeliveryRouter({ service, loadAdapter, clock,
+          readLivePolicy: ({ adapter }) => readInstalledLivePolicy({ dataHome,
+            adapterId: adapter.id }) }));
+    return (await router).offer(message);
+  } };
+};
 
 export async function main({ managerRoot = null, packageRoot, managementOnly = false } = {}) {
-const adapters = Object.fromEntries(ALL_ADAPTERS().map(adapter => [adapter.id, adapter]));
 
 // The composition root is the only place allowed to reach for ambient time and
 // randomness; everything below it receives them as ports.
@@ -24,14 +37,12 @@ const runtime = {
   stderr: process.stderr,
   clock: { now: () => new Date().toISOString() },
   ids: { next: kind => createId(kind, randomBytes) },
-  createDeliveryRouter: ({ service, clock, dataHome }) =>
-    createDeliveryRouter({ service, adapters, clock,
-      readLivePolicy: ({ adapter }) => readInstalledLivePolicy({ dataHome,
-        adapterId: adapter.id }) }),
+  createDeliveryRouter: lazyRouter,
   // Chats a client holds before their first turn, registered before status
   // is read so a peer can address them (#167).
-  registerNativeSessions: ({ workspaceId, dataHome }) =>
-    registerDiscoveredSessions({ adapters, workspaceId, dataHome, env: process.env }),
+  registerNativeSessions: async ({ workspaceId, dataHome }) =>
+    (await import("@agents-can-communicate/hook-runner")).registerDiscoveredSessions({
+      loadAdapters, workspaceId, dataHome, env: process.env }),
   // Asked only by `acc config init`, and only when stdout is a terminal. There
   // was no port here at all, so the question went to the fallback that always
   // answers no: in a real terminal the command printed "not written" and never

package/bin/entrypoints/antigravity-relay-binding.mjs

@@ -3,7 +3,7 @@ import { loadSessionBinding, storeNativeAttempt } from "@agents-can-communicate/
 import { createCoordinationService } from "@agents-can-communicate/core";
 import { establishNativeBinding } from "@agents-can-communicate/hook-runner/native-binding";
 import { withSessionLifecycle } from "@agents-can-communicate/hook-runner/session-lifecycle";
-import { readInstalledLivePolicyState } from "@agents-can-communicate/installer";
+import { readInstalledLivePolicyState } from "@agents-can-communicate/installer/live-policy";
 import { openFilesystemStore } from "@agents-can-communicate/storage-filesystem";
 
 // No hook runs when the agent starts a relay mid-turn, and the next

package/docs/CAPABILITIES.md

@@ -28,6 +28,9 @@ Run `acc doctor` in the project when observed behavior differs from this page. I
 the installed client version, platform, effective capability, and fallback instead of
 assuming that a newer or differently packaged client behaves like a captured one.
 
+The optional [ACC indicator](STATUS_INDICATOR.md) shows this chat's reception mode and
+known failures in supported client footers. It reads local state; it is not a transport probe.
+
 ## Certified support
 
 Each column names the version that recorded the capture, on `darwin-arm64`. Every later

package/docs/CLI.md

@@ -37,8 +37,8 @@ option value remains data: `--body --help` sends the literal body `--help`.
 | `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` | `--resource` | `--session`, `--generation`, `--mode`, `--enforcement`, `--reason`, `--lease` |
-| `acc release` | `--claim` or `--resource` | `--session`, `--generation`, `--authority` (`human` or `policy`), `--reason` |
+| `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 |
@@ -175,6 +175,12 @@ held.
 ```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
@@ -182,10 +188,31 @@ creates an advisory claim: omitted `--enforcement` always means `advisory`, even
 certified clients. Request `--enforcement guarded` explicitly when needed; an incapable
 live participant still downgrades workspace protection. MCP claims are always advisory.
 
-Exit code `5` means a conflict. Ordinary sessions release only their own claims. Releasing
-another owner's claim requires `--authority human` or `--authority policy`, identifying the
-actual human decision or approved policy that permits the release; explain it with
-`--reason`. A peer's request alone is not force-release authority.
+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
 
@@ -360,7 +387,7 @@ before leaving, request the concrete continuation and obtain a substantive reply
 
 | Command | Flags |
 |---|---|
-| `acc install` | `--adapter`, `--home`, `--delivery off|actionable|all`, `--dry-run`, `--downgrade` |
+| `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` |

package/docs/MCP.md

@@ -50,8 +50,8 @@ successfully yet refuse tool calls; that is distinct from a protocol handshake f
 | `acc_status` | — | — |
 | `acc_sync` | — | `cursor`, `scope: delta|full|history`, `limit: 1..500`, `kind`, `messageId`, `current` |
 | `acc_work` | `summary` and `mode`, or `clear: true` | `state`, `resourceHints` |
-| `acc_claim` | `action`; `resource` for acquire, `claimId` for renew | `mode`, `reason`, `leaseSeconds` where valid |
-| `acc_release` | `claimId` | — |
+| `acc_claim` | `action`; exactly one of `resource` or `resources` for acquire, `claimId` for renew | `mode`, `reason`, `leaseSeconds` where valid |
+| `acc_release` | exactly one of `claimId`, `claimIds`, `resource`, `resources`, or `all: true` | — |
 | `acc_message` | `to`, `subject`, `body` | `kind`, `obligation`, `clientMessageId`, `supersedes`, `withdraws` |
 | `acc_request` | `toParticipantId`, `title` | `detail`, `clientMessageId` |
 | `acc_inbox` | — | `messageId`, `cursor`, `limit: 1..500` |
@@ -108,6 +108,46 @@ session that has not joined, omit `toParticipantId` to leave a workspace handoff
 session can recover that historical handoff through the history list and exact read;
 its addressed inbox will not contain past workspace broadcasts.
 
+## Acquire and release claims
+
+Acquire one resource with `acc_claim {action: "acquire", resource: "file:src/a.mjs"}`.
+Use a nonempty `resources` array for an atomic batch:
+
+```json
+{
+  "action": "acquire",
+  "resources": ["file:src/a.mjs", "file:src/b.mjs"],
+  "mode": "exclusive",
+  "reason": "updating both modules",
+  "leaseSeconds": 1800
+}
+```
+
+Shared mode, reason, and lease apply to every resource. Duplicate resources after
+normalization are rejected. A conflict changes no claims, including existing leases.
+Batch error `details.conflicts` identifies each blocked requested resource and its holders.
+Repeating acquisition renews this session's existing claims on those resources.
+`action: "renew"` still accepts only one `claimId` and its optional lease.
+
+Release uses one mutually exclusive selector: `claimId`, a nonempty `claimIds` array,
+`resource`, a nonempty `resources` array, or `all: true`. For example,
+`acc_release {resources: ["file:src/a.mjs", "file:src/b.mjs"]}` releases both claims atomically.
+Duplicate selectors after normalization are rejected. Explicit targets must exist and
+belong to this session. A missing or foreign target fails without removing any claims.
+MCP offers no force-release authority.
+
+`acc_release {all: true}` releases only this session's current claims in its workspace.
+An empty set succeeds, including for a solo ephemeral session. Release keeps the session
+and intent open. `acc_work {clear: true}` clears intent, `acc_ack` acknowledges a message,
+and `acc_finish` records a handoff and closes presence.
+
+Scalar acquisition returns the existing Claim. Scalar release returns `{released: claimId}`.
+Array acquisition returns `{claims: [...]}`. Array release and `all: true` return
+`{released: [...]}`. Array inputs keep these shapes even with one element.
+`all: true` can return `{released: []}`.
+Repeating an explicit release after its targets were removed remains an error.
+Each `all: true` call selects the current owned set, so a retry can release newly acquired claims.
+
 ## Account for the manual boundary
 
 The generic MCP capability declaration is all false:

package/docs/PROTOCOL.md

@@ -45,6 +45,25 @@ exclusive mode, advisory or guarded enforcement, reason, and lease timestamps. C
 acquisition and conflict detection are atomic. Presence becoming stale never releases a
 claim; expiry or an explicit release does.
 
+Batch acquisition validates a nonempty resource list before writing. Duplicate resources
+after normalization are rejected. Mode, enforcement, reason, and lease apply to the whole
+batch. If any requested resource conflicts, no claim is created or renewed. Batch error
+`details.conflicts` lists the blocked requested resources and their blocking claims.
+A successful repeated acquisition renews the owner's existing claims on those resources.
+
+Batch release selects claims by IDs, canonical resources, or the calling session's whole
+owned set. Exactly one selector family is accepted. Explicit selectors must be nonempty
+and unique after normalization. A missing or foreign target prevents every removal.
+The whole-set selector releases only that session's claims in its workspace and succeeds
+when the set is empty, including for a solo ephemeral session. Batch release has no
+force-release authority. The existing single-claim human or policy release remains separate.
+
+Explicit release retries still fail once their targets were removed. A whole-set retry
+selects the current owned set, which can include claims acquired after the first call.
+Release keeps the session and intent open. Clearing intent, acknowledging messages, and
+finishing with a handoff remain separate operations. Batch operations retain individual
+claim records and per-claim events. They add no record schema or event type.
+
 ## Message envelope
 
 Every message contains:

package/docs/STATUS_INDICATOR.md

@@ -0,0 +1,133 @@
+# The ACC indicator
+
+The indicator describes incoming messages for the current chat. It does not describe
+other chats, confirm that a message was read, or promise when an agent will answer.
+
+In Claude Code, only the status glyph carries color: green for `●`, warning color for
+`!`, and neutral for `…`. All supported clients use the same fixed green (`#2c7a39`) for
+`●`, without dimming. Claude uses its theme for the other states. The name
+and `turn`/`inbox` qualifier keep the ordinary footer color. No background is added.
+
+Antigravity's command emits ANSI foreground color around only the glyph, even when
+stdout is a pipe. Existing installed commands need no new arguments. `--json` and
+`--details` keep their plain, uncolored output.
+
+| Display | Meaning |
+|---|---|
+| `ACC ●` | ACC is active. This chat has an automatic delivery binding with no newer recorded failure. A busy client can queue a request. |
+| `ACC ● · turn` | ACC is active. Messages arrive on the next normal turn. |
+| `ACC ● · inbox` | ACC is active. The agent reads messages through `acc inbox`. This does not imply a polling schedule. |
+| `ACC …` | The Claude indicator is reading state or waiting up to five seconds for startup hooks. Failed reads keep it until a read answers or three reads in a row fail. |
+| `ACC ! · turn` or `ACC ! · inbox` | ACC observed a failure. The qualifier names the remaining reception path. |
+| `ACC !` | The chat is not registered, or the indicator cannot read its state. |
+
+An unsupported wake-up capability is a normal `turn` or `inbox` mode. A failure of an
+expected automatic channel retains `!`; it does not silently become a normal fallback.
+The current `--delivery off` setting also uses the normal fallback. Details explain that
+setting. Enabling the indicator does not enable automatic delivery or change its consent.
+
+An idle chat does not lose its indicator because its heartbeat or delivery lease is old.
+The sender verifies and renews an expired lease when it next attempts delivery. The badge
+uses local observations. It does not test the endpoint on each refresh. Lease validity is
+available in JSON as `leaseCurrent`, separately from reception and health.
+Offer diagnostics are published separately from delivery. A slow diagnostic write
+does not hold up offers to the next participant or change delivery receipts.
+
+## Enable or disable
+
+```sh
+acc install --adapter claude_code --indicator on
+acc install --adapter antigravity --indicator on
+acc install --adapter kimi --indicator on
+acc install --adapter grok --indicator on
+acc install --adapter claude_code --indicator off
+```
+
+The initial preference is off. A later install or automatic update keeps the saved choice
+when `--indicator` is omitted. `--dry-run` makes no changes. Normal uninstall removes the
+indicator and keeps status-line settings that the user changed.
+
+## Client surfaces
+
+| Client | Integration and limits |
+|---|---|
+| Claude Code | From 2.1.287: a plugin mod adds a native footer label. It does not change `settings.statusLine`. Use `/reload-plugins` in an open session after installing. Client policy can disable mods. |
+| Antigravity CLI | A status-line command adds ACC below the built-in line. If a custom command exists, ACC passes it the original stdin and appends the badge. Existing padding and stacking choices remain. Start a new CLI session after changing settings. |
+| Codex and Gemini CLI | No automatic indicator installation. Their native status lines do not expose this command surface. |
+| Kimi Code | From 2.1.1: compose one line with the existing custom command, or available mode/model/cwd/branch fields. Run `/reload-tui`. The native context/warnings line remains. |
+| Grok | From 1.0.46: compose the optional status row with the existing command, or configured built-in items. ACC adds idle refresh once per second unless an interval is already configured. Start a new Grok session. |
+| Other hosts | A host that provides the native session id can run `acc-indicator` as a custom widget. This does not certify that host's UI integration. |
+
+Claude prints one diagnostic when a new problem appears. `/acc-status` shows the current
+explanation and recovery step without a model request. Healthy refreshes do not print
+messages. A read that fails or does not answer describes the indicator, not the chat.
+The badge keeps the last observed state until three reads in a row fail; only then
+does it show `!` and print the diagnostic. A slow read says so and does not suggest
+reinstalling, because a reinstall cannot make a busy machine answer sooner. Antigravity's command surface has no equivalent notification: only a problem
+adds `acc doctor` to the compact line. Run that command in the project for diagnostics.
+
+The Antigravity wrapper runs an existing enabled command with a 700 ms limit and a 64 KiB
+output limit. A disabled old command stays disabled. Disabling ACC restores only the
+fields ACC changed and still owns. A user replacement command takes precedence.
+Removing or replacing Antigravity's ACC command also survives repeated updates.
+To add ACC again after that edit, disable the indicator and then enable it.
+
+On POSIX, timeout, output overflow and indicator cancellation stop the previous
+command's owned process group. Windows uses a detached Node launcher because a
+detached shell loses its standard input handles. The launcher starts a hidden shell
+with the original stdin/stdout. ACC stops the launcher and its descendants with
+`taskkill /T /F`. Scripts that leave background processes
+running after the shell exits must stop those processes themselves on Windows.
+
+## Kimi and Grok composition
+
+ACC puts its compact badge first so a narrow terminal cannot truncate it behind a long
+path. Existing custom commands receive the original stdin. Kimi keeps their first output
+line; Grok retains the remaining lines. Disabling or uninstalling restores the old command
+and only the presentation fields ACC still owns. A later user replacement takes precedence.
+
+Kimi passes `sessionId`; Grok passes `session_id`. An empty Kimi ID is its welcome screen,
+before a session exists, so ACC retains the footer without a registration error.
+A registered Kimi normally shows `ACC ● · turn`; Grok shows `ACC ● · inbox`.
+
+Kimi's snapshot does not expose goals, background task counts, thinking effort, swarm/tower
+badges, detailed Git status, or rotating tips. These first-line elements cannot be retained
+when composing the built-in footer; the native context/warnings line remains. Existing
+custom commands can retain any extra information they already render. Kimi limits the entire
+command to 300 ms; ACC bounds its own work to 180 ms after module loading and the previous
+command to 80 ms. A host timeout can retain the last line until a successful refresh.
+
+TOML comments and unrelated settings are retained. Ambiguous inline status tables or dotted
+status declarations are refused without rewriting them; use a normal `[status_line]` or
+`[ui.status_line]` table. The version floors above reflect native UI captures, not new
+message-delivery certification.
+
+## Read-only command
+
+```sh
+printf '%s' '{"session_id":"native-session-id"}' | acc-indicator --adapter claude_code
+acc-indicator --adapter claude_code --native-session native-session-id --details
+acc-indicator --adapter claude_code --native-session native-session-id --json
+```
+
+Antigravity supplies `conversation_id`; `session_id` is also accepted. The reader selects
+the saved room for that adapter and native id. It never guesses from the current directory
+or scans other sessions. Output contains no generation token, endpoint, or message body.
+
+The reader does not acquire a runtime lease, schedule updates, create a workspace,
+recover a journal, send a heartbeat, renew delivery, or contact a client socket. The
+managed launcher resolves the active runtime on each call. A concurrent update can cause
+one failed read; a later refresh can recover without retaining the outgoing generation.
+
+The router publishes an optional, bounded observation after a transport accepts or rejects
+a send. For records with equal timestamps, a delayed older write cannot replace a newer
+success or failure.
+The indicator compares the resulting observation with the latest hook handshake for the same generation.
+This diagnostic contains only time, outcome, and a closed reason code. Delivery receipts
+and immutable history remain authoritative. An unavailable diagnostic cannot fail a send.
+
+An unreadable state produces a closed error and a recovery command. It never renders raw
+file content. A command stops waiting after 1.5 seconds. Claude refreshes every five seconds,
+with one-second checks during its bounded startup period. Claude allows each read five
+seconds: on a loaded machine the command's own start took up to 1.3 seconds inside
+Claude, before its 1.5-second wait begins.

package/docs/TROUBLESHOOTING.md

@@ -212,8 +212,8 @@ per-session lines in `acc doctor`, or `nativeDelivery.sessions[].lastAttempt` in
 
 - An absent or `off` policy means the installation record has no live-delivery consent
   for that client. Run `acc install --adapter <adapter> --delivery actionable` (or `all`).
-- `client_process_unknown` means ACC could not identify the client process. A new client
-  session repeats that lookup.
+- `client_process_unknown` means ACC could not identify the client process, for example
+  when a loaded machine slowed the lookup at session start. Each later prompt repeats it.
 - For Claude Code, `native_endpoint_unavailable` means the hook environment had no
   `CLAUDE_CODE_MESSAGING_SOCKET`, or the socket failed ACC's safety checks.
   `native_session_unavailable` means the session registry is missing or names another

package/docs/WHY_ACC.md

@@ -3,11 +3,14 @@
 ACC fits work that spans clients from different vendors. Claude Code sessions can message
 each other through Claude Code's
 [cross-session messaging](https://code.claude.com/docs/en/cross-session-messaging), and
-`codex queue` queues a message for another Codex session. Neither client offers a way to
-message the other's sessions. When you ask another vendor's model for a review,
-build related features in two clients, or switch clients in the middle of a feature, the
-sessions need to ask and answer each other without making you carry every sentence between
-windows.
+`codex queue` queues a message for another Codex session. From Claude Code,
+[OpenAI's Codex plugin](https://github.com/openai/codex-plugin-cc) can ask Codex for a
+review, hand it a task, or move the conversation into a Codex thread; it runs Codex under
+Claude Code, in that direction only, and Codex can import Claude Code sessions the same way.
+Neither client offers a way to message a session you opened yourself in the other one. When
+you build related features in two clients, ask another vendor's model for a review from either
+side, or switch clients in the middle of a feature, the sessions need to ask and answer each
+other without making you carry every sentence between windows.
 
 Each session keeps its own context, permissions, checkout, and model.
 
@@ -22,7 +25,9 @@ resources, and hand off context.
 ```mermaid
 flowchart TD
   A["Do all your sessions run in Claude Code, or all in Codex?"] -->|yes| V["Try the client's own messaging first"]
-  A -->|no| B["Must they keep separate ownership and permissions?"]
+  A -->|no| A2["Do you only need Claude Code to call Codex for a review, a task or a handoff?"]
+  A2 -->|yes| P["OpenAI's Codex plugin for Claude Code does that from inside Claude Code"]
+  A2 -->|no| B["Must they keep separate ownership and permissions?"]
   B -->|no| M["A managed agent runtime may fit better"]
   B -->|yes| C["Do they need direct questions, durable replies, or claim awareness?"]
   C -->|yes| Y["ACC fits this workflow"]
@@ -58,8 +63,9 @@ session that is not polling for anything. For clients without an integration, AC
 own [MCP server](MCP.md); without hooks, the agent there reads its inbox when it chooses to.
 
 Claude Code documents its inbox socket for scripts and hooks, and `codex queue` is a command
-any process can run, so two sessions can be wired together by hand. What that leaves to you is
-what ACC does: one list of peers across clients, so a session finds the other without a socket
+any process can run, so two sessions can be wired together by hand. OpenAI's plugin covers one
+direction, Claude Code calling Codex, with Codex started under Claude Code. What that leaves to
+you is what ACC does: one list of peers across clients, so a session finds the other without a socket
 path or a thread id; a reply that returns to the sender in its own client; messages and
 handoffs kept for a session that is closed or not open yet; receipts that show what happened
 to each message; and instructions installed in each client, so agents use it without being

package/node_modules/@agents-can-communicate/adapter-antigravity/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agents-can-communicate/adapter-antigravity",
-  "version": "0.10.4",
+  "version": "0.11.1",
   "private": true,
   "type": "module",
   "exports": {

package/node_modules/@agents-can-communicate/adapter-antigravity/plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "acc",
-  "version": "0.10.4",
+  "version": "0.11.1",
   "description": "Coordinate this Antigravity CLI session with other AI agent sessions working in the same workspace."
 }