agents-can-communicate 0.10.3 → 0.11.0

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/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,128 @@
+# 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 for startup hooks, for at most five seconds. |
+| `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. 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.

package/docs/TROUBLESHOOTING.md

@@ -158,6 +158,16 @@ delivery, start Codex without it; put a setting you need in `config.toml` instea
 If a reply stays queued with `transport_permission_denied`, the sender's permissions
 blocked local transport. This is distinct from an unavailable recipient. The message was
 recorded successfully; the error does not mean it was read or acknowledged.
+For Codex sends, use the exact installed ACC wrapper through the client's approved
+command path (`exec_command` with `sandbox_permissions: "require_escalated"`). The
+installed ACC prefix rule can authorize that command. Keep it separate from other
+shell commands. If delivery was already attempted, retry the same arguments and
+the original `--client-message-id` printed by the CLI. This retries the recorded
+message instead of recording another one. An initial execution refusal records
+nothing; a refused retry does not erase an earlier recorded message.
+On Codex 0.162.0 on macOS, even an installed socket allowlist did not permit direct
+access to the daemon socket from the sandbox. A configured profile alone therefore
+does not prove that a sandboxed sender can reach another Codex session.
 On Codex 0.153.4 or newer, rerun `acc install --adapter codex` with existing
 live consent. Add `--delivery actionable` when new consent is required, then start a new session.
 With ACC 0.8.0 or 0.8.1, every live offer from a Codex session to Claude Code failed this way:

package/docs/UPGRADING.md

@@ -1,5 +1,21 @@
 # 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

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.3",
+  "version": "0.11.0",
   "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.3",
+  "version": "0.11.0",
   "description": "Coordinate this Antigravity CLI session with other AI agent sessions working in the same workspace."
 }

package/node_modules/@agents-can-communicate/adapter-antigravity/plugin/skills/acc/SKILL.md

@@ -64,19 +64,43 @@ Do this once, not every turn. Update it only when the scope or mode materially
 changes. `--hint` is important: it lets ACC match your plan against a peer's
 claim. Intent is awareness, not permission.
 
-Before changing shared files, claim the smallest useful resource:
+Before changing shared files, claim the smallest useful resources in one operation:
 
 ```bash
-{{ACC}} claim --resource 'file:packages/core/**' --reason "porting the store"
+{{ACC}} claim --resource 'file:packages/core/**' \
+  --resource 'file:packages/protocol/**' --reason "porting the claim model"
 ```
 
-Exit 5 means a conflict. Do not work around it silently. Narrow your scope,
-contact the owner, or ask the human. Give a claim back explicitly when useful:
+Repeat `--resource` for an atomic batch, or supply it once for one claim.
+Shared mode, enforcement, reason, and lease apply to every resource. Duplicate resources after
+normalization are rejected. Exit 5 means a conflict: no claim is created or
+renewed. Batch `details.conflicts` names blocked resources and their holders.
+Narrow your scope, contact the owner, or ask the human. Repeating a successful
+claim command renews your existing claims on those resources.
+
+Release selected claims when useful:
 
 ```bash
-{{ACC}} release --resource 'file:packages/core/**'
+{{ACC}} release --resource 'file:packages/core/**' \
+  --resource 'file:packages/protocol/**'
 ```
 
+Choose exactly one selector family: repeated `--resource`, repeated `--claim`,
+or `--all`. Duplicate selectors after normalization are rejected. A missing or
+foreign explicit target fails without releasing any claims. Repeating an explicit release after its targets were removed is an error.
+Batch release accepts no force-release authority.
+
+To release all your claims while keeping your session and intent open:
+
+```bash
+{{ACC}} release --all
+```
+
+This selects only your session's current claims in its workspace. An empty set
+succeeds. Each retry selects the current set and can release newly acquired claims.
+Use `work --clear` to clear intent, `ack` to acknowledge a message, and `finish`
+to record a handoff and close your ACC presence.
+
 ## Communicate only when it changes another agent's work
 
 Send a message for a dependency, conflict, direct question, decision, or

package/node_modules/@agents-can-communicate/adapter-antigravity/src/adapter.mjs

@@ -10,6 +10,7 @@ import { detectAntigravity, doctorAntigravity, installAntigravity, planAntigravi
 import { bindNativeSession, nativeActivationHint, offerMessage, planNativeActivation,
   probeNativeDelivery, refreshNativeSession } from "./native-delivery.mjs";
 import { PROTOCOL_CONTRACT } from "./relay-endpoint.mjs";
+import { renderAntigravityIndicator } from "./indicator-render.mjs";
 
 // The version this client has been captured on. Nothing earlier was measured,
 // and later releases - this client ships every few days - are judged by this
@@ -63,6 +64,8 @@ export function createAntigravityAdapter() {
   return defineAdapter({
     id: "antigravity",
     displayName: "Antigravity CLI",
+    statusIndicator: { minimumVersion: "1.0.6", reload: "start a new CLI session",
+      renderText: renderAntigravityIndicator },
     // What the official installer puts on PATH, and what a version probe has to
     // spawn: `agy --version` answers `1.2.7`. Presence liveness also walks the
     // hook's process ancestry for this basename to learn the client's own pid.