agents-can-communicate 0.9.1 → 0.10.1

package/README.md

@@ -1,33 +1,35 @@
 # Agents Can Communicate (ACC)
 
-**Let your AI coding sessions talk to each other.**
+**The message your clients can’t send each other.**
 
-ACC connects independent AI coding sessions in the clients you already use. They can ask each
-other questions, exchange reviews, and leave handoffs for another session to continue.
+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.
 
 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
-others.
+others. If all your sessions run in one of these two clients, try its own messaging first.
 
 ```mermaid
 flowchart TB
     you["You choose the tools and work"]
     codex["Codex<br/>Feature A"]
     claude["Claude Code<br/>Feature B"]
-    gemini["Gemini CLI<br/>Feature C"]
+    antigravity["Antigravity CLI<br/>Feature C"]
     acc["Communication via ACC"]
 
     you -.-> codex
     you -.-> claude
-    you -.-> gemini
+    you -.-> antigravity
     codex <--> acc
     claude <--> acc
-    gemini <--> acc
+    antigravity <--> acc
 
-    subgraph handoff["When you switch models"]
+    subgraph handoff["When you switch clients"]
         direction LR
-        current["Current<br/>session"] --> saved["Handoff<br/>Done · Decisions<br/>Next steps"]
-        saved --> next["Next<br/>session"]
+        current["Claude Code<br/>session"] --> saved["Handoff<br/>Done · Decisions<br/>Next steps"]
+        saved --> next["Codex<br/>session"]
     end
     acc ~~~ handoff
 
@@ -35,7 +37,7 @@ flowchart TB
     classDef session fill:#fff,stroke:#ced4d9,color:#202a35
     classDef shared fill:#e8edff,stroke:#385cde,color:#202a35
     class you human
-    class codex,claude,gemini,current,next session
+    class codex,claude,antigravity,current,next session
     class acc,saved shared
     style handoff fill:transparent,stroke:#ced4d9
     linkStyle 3,4,5,6,7 stroke:#385cde,stroke-width:2px
@@ -43,14 +45,16 @@ flowchart TB
 
 ## When ACC helps
 
-- **Switch models mid-feature.** When a limit approaches or you want another model’s approach,
-  leave a handoff with decisions and unfinished work for the next session.
-- **Get a second opinion.** Ask another session to review a specific change and send its
-  findings directly to the implementing agent.
-- **Bring parallel features together.** Let sessions working on frontend and backend ask each
-  other about a shared API before building around different assumptions.
+- **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.
+- **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.
 
-## Try one handoff
+## Try one review across 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
@@ -66,45 +70,41 @@ 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.
 
-For example, when pausing work on an account-registration feature, ask:
+Open Claude Code and Codex in the same project. After Claude Code has changed something, for
+example an account-registration form, ask it:
 
 ```text
-Save a partial handoff in ACC for the registration feature. Include
-what is done, our decisions, what remains, and what you actually
-verified. I will continue in another session.
+Ask the Codex session in ACC to review the registration form change
+you just made. Name the files and what it should check.
 ```
 
-Open another supported client in the same project and ask:
+Then ask Codex:
 
 ```text
-Continue the registration feature from its ACC handoff. Check the
-saved decisions against the current files, then take the next
-unfinished step. Ask me if the scope is unclear.
+Answer the review request in ACC. Read the files it names, check
+what it asks, and reply with what you found.
 ```
 
-The next session should identify the saved decision and begin the remaining work. It can find
-the handoff even if it was opened after the previous session stopped.
-
-Save the handoff while the first model can still respond. ACC preserves explicitly recorded
-context; it cannot recover details that were never saved.
+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.
 
 ## Client support
 
-Integrations are available for **Antigravity CLI, Claude Code, Codex, Gemini CLI, Grok, and
-Kimi Code**. Other
-clients can connect through [MCP](docs/MCP.md) with their own configuration and coordination
-instructions.
+Integrations are available for **Antigravity CLI, Claude Code, Codex, Grok, and Kimi Code**.
+Other clients can connect through [MCP](docs/MCP.md) with their own configuration and
+coordination instructions.
 
 Automatic delivery depends on the client version and platform. Verified integrations can
 provide messages at the next normal turn; other sessions read their ACC inbox explicitly.
 
 Experimental live delivery can wake eligible Claude Code, Codex and Antigravity CLI
-sessions, conversations in the Antigravity desktop app, and local Code sessions in Claude.app. It requires opt-in and an active verified
-connection, is off by default, and can spend model tokens. Claude Code sessions wake through
-the inbox that Claude Code itself opens, so you start Claude Code with your ordinary command.
-A busy Claude Code session gets the message between two tool calls. A busy Codex session gets
-it when the current turn ends. Chats in the Codex app run on the app's own server and get
-messages at their next turn.
+sessions, conversations in the Antigravity desktop app, and local Code sessions in Claude.app.
+It requires opt-in and an active verified connection, is off by default, and can spend model
+tokens. Claude Code sessions wake through the inbox that Claude Code itself opens, so you start
+Claude Code with your ordinary command. A busy Claude Code session gets the message between two
+tool calls. A busy Codex session gets it when the current turn ends. Chats in the Codex app run
+on the app’s own server and get messages at their next turn.
 
 See [client capabilities](docs/CAPABILITIES.md) for exact support. Run `acc doctor` from your
 project if a peer is missing or delivery differs from what you expect; see
@@ -125,9 +125,11 @@ Automatic updates are enabled on first install. Use `acc update --auto off` to d
 [update controls](docs/UPGRADING.md) for details.
 
 MIT-licensed and permanently noncommercial. Try it on one real task and
-[tell us how it went](https://github.com/automatis-tools/agents-can-communicate/discussions/categories/show-and-tell),
-including where you still had to carry messages yourself. Bugs belong in
-[issues](https://github.com/automatis-tools/agents-can-communicate/issues).
+[open an issue](https://github.com/automatis-tools/agents-can-communicate/issues/new/choose)
+with what happened: whether it worked, where it broke, or where you still had to carry
+messages between sessions yourself. If it worked, watch the repository’s releases to hear
+about the next one. Longer write-ups and setups are welcome in
+[Discussions](https://github.com/automatis-tools/agents-can-communicate/discussions).
 
 [Documentation](docs/index.md) ·
 [Contributing](https://github.com/automatis-tools/agents-can-communicate/blob/main/AGENTS.md)

package/bin/acc-update-worker.mjs

@@ -1,5 +1,6 @@
 #!/usr/bin/env node
-// Private detached updater. It never opens workspace state or runs a model.
+// Private detached updater. It never runs a model; the only workspace state it
+// opens is an older store it migrates to this generation's contract.
 import path from "node:path";
 import { fileURLToPath } from "node:url";
 import { runWorker, recordWorkerFailure } from "@agents-can-communicate/cli/managed-worker";

package/bin/entrypoints/hook-output.mjs

@@ -57,6 +57,8 @@ function tryWrite(stream, output) {
 }
 
 const RECOVERY = new Map([
+  ["store_migration_required", ": store contract 6 requires explicit migration; stop old ACC"
+    + " clients and unmanaged store users, then run acc doctor --migrate-store in this workspace"],
   ["workspace_contains_runtime", ": workspace contains ACC runtime state; open a project"
     + " directory and restart the client (or set ACC_DATA_HOME outside the workspace)"],
   ["workspace_path_unquotable", ": this directory's path has a double quote, $, ` or %, which"

package/docs/ARCHITECTURE.md

@@ -239,6 +239,25 @@ unknown holder postponed, is recorded as unfinished, and the next ACC command an
 later starts the worker that finishes it. Parsed help, version, and update recovery remain
 available when workspace admission is unavailable.
 
+Store contract 7 adds exact transaction loads and two rebuildable indexes:
+`messageByClientKey` and `receiptsByMessage`. Content-addressed pages contain
+portable key tuples and record references, never message bodies. Each page is
+bounded by 32 entries and 64 KiB; radix branches have at most 16 children.
+Under the writer mutex, the cache is trusted only for the same workspace and the
+current idle journal generation. Every message/receipt put or remove advances
+that durable authority. Other journalled writes carry valid unchanged roots
+forward, while ordinary single-record heartbeats keep their direct publication.
+Authoritative writes commit first; cache pages and the manifest are unflushed
+derived data. Cache loss or corruption requires verified rebuilding and cannot
+turn a recorded message into a failed send.
+
+Contract 6 writers can bypass that authority, so migration is explicit.
+`doctor --migrate-store` holds runtime admission before the workspace writer
+mutex, refuses incompatible or unknown live holders, recovers decided journals,
+builds the complete cache, and durably replaces the identity last. The library
+requires explicit opt-in after unmanaged callers are quiesced. A hook never
+performs this migration. Record schemas and journal format 2 are unchanged.
+
 An independent worker downloads npm packages with lifecycle scripts disabled, checks exact
 stable package identity and the discovered integrity, and health-checks the staged runtime.
 Installer detection and planning happen before exclusive admission. The worker then checks
@@ -248,8 +267,13 @@ every integration, and only publishes the new active pointer after all applicati
 remains fenced and repairs forward, with the old active pointer retained but normal
 workspace admission unavailable until recovery completes. Native bindings cease holding
 after observed SessionEnd cleanup or confirmed process death; the vendor daemon may remain
-running. Unknown PIDs remain holds until lifecycle cleanup. Presence TTL, `acc finish`,
-and delivery off alone do not prove native lifecycle end. Normal background updates never
+running. A binding that names no client process is judged by its session record instead
+(#273): it stops holding when the record is gone, when the record names a process that has
+exited, or, with no process recorded, when ACC's presence rule calls the session offline -
+closed, or 30 minutes without a heartbeat. A live recorded process, or a record that cannot be
+read, keeps it a hold. A client that wakes later runs its next hook through the launcher on
+the active generation. For a binding that names its client, presence TTL, `acc finish`, and
+delivery off do not prove native lifecycle end. Normal background updates never
 restart a vendor daemon. An explicitly approved maintenance job can do so through the
 adapter lifecycle port: it waits for idle work, validates exact process identity, stops
 the service under the admission fence, refreshes integrations, and restores and verifies

package/docs/CLI.md

@@ -362,7 +362,7 @@ before leaving, request the concrete continuation and obtain a substantive reply
 |---|---|
 | `acc install` | `--adapter`, `--home`, `--delivery off|actionable|all`, `--dry-run`, `--downgrade` |
 | `acc uninstall` | `--adapter`, `--home`, `--dry-run` |
-| `acc doctor` | `--home`, `--repair` |
+| `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) |
@@ -459,6 +459,16 @@ workspace state; `doctor --repair` remains blocked. Native clients may still req
 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 <id>`, `acc heartbeat --session <id> --generation <token>`, and

package/docs/GETTING_STARTED.md

@@ -1,6 +1,7 @@
 # Getting started
 
-Install ACC, open the AI sessions you already use, and give them related work. Supported
+Install ACC, open the AI sessions you already use in clients from different vendors, such as
+Claude Code and Codex, and give them related work. Supported
 integrations make peers visible and teach each agent how to communicate. You do not need to
 carry messages between windows or add coordination instructions to your task prompts.
 
@@ -16,8 +17,8 @@ pair or session-bound ACC MCP tools. See [CLI ownership](CLI.md#coordinate-from-
 ACC requires Node.js 24 or newer on macOS, Linux, or Windows 10 or 11. On Windows, read
 [Windows](#windows) below first.
 
-Already using ACC? Follow the [upgrade guide](UPGRADING.md) for the 0.4.x → 0.5.0
-update or the data-format boundary when upgrading from 0.3.1.
+Already using ACC? Follow the [upgrade guide](UPGRADING.md#from-09x): from 0.9.x, each
+store moves to contract 7 once no session still runs 0.9.x code.
 
 ```bash
 npm install -g agents-can-communicate

package/docs/UPGRADING.md

@@ -1,5 +1,62 @@
 # Upgrading
 
+## Store contract 6 to 7
+
+ACC moves each workspace's store from contract 6 to 7 by itself, right after an update
+activates a contract-7 runtime. The activation already waits until no client runs older ACC
+code, so at that point the migration is safe. It builds the message and receipt indexes from
+validated live records, then replaces the store identity last. Message bytes, receipt bytes,
+workspace identity and initialization time are preserved. There is no reverse migration:
+version-6 code refuses a version-7 store.
+
+A store that a live older client still holds, or whose migration fails, stays on contract 6.
+The next ACC command or hook a minute or more later retries it. Until then, coordination is
+paused in that workspace: Claude Code and Codex show a message about it, other clients write it
+to stderr, `acc status` names it, and `acc doctor` names the command. To migrate a workspace at
+once, stop older ACC clients and any program that imports the store directly, then run in that
+workspace:
+
+```bash
+acc doctor --migrate-store
+```
+
+The command refuses old or unknown live runtime holders, does not install or activate a
+runtime, contact npm, or restart clients. If it is interrupted, run it again.
+`doctor --repair` never migrates a store, and hooks never change a store's format. Runtime
+admission cannot see unmanaged direct library users; stop them before an update.
+
+## From 0.9.x
+
+Update as usual:
+
+```bash
+acc update
+acc version
+acc doctor
+```
+
+0.10.0 moves every store from contract 6 to 7, as described above. What you see:
+
+- **Activation waits for 0.9.x sessions.** A client session that started under 0.9.x holds
+  contract 6 until it ends. `acc update` downloads 0.10.0 and reports
+  `ACC 0.10.0 is ready; waiting for N active or unidentified process(es)`, and `acc doctor`
+  names them. A session you start while 0.10.0 waits still runs 0.9.x, so activation needs a
+  moment when no such session runs: end or restart them together.
+- **Stores move by themselves.** Right after 0.10.0 activates, it migrates every workspace's
+  store; you run no command.
+- **0.9.x and 0.10.0 never share a workspace.** 0.9.x code refuses a contract-7 store. This
+  matters only for a copy of ACC that runs outside the managed runtime, such as an npm-global
+  0.9.x on another `PATH` or a development checkout: update or stop it.
+- **Sending a message reads less of the store.** A send and its retries use a bounded index
+  instead of rereading unrelated messages and receipts.
+
+0.10.1 lets this update finish where 0.10.0 could stay pending. A session that ended without
+naming its client process could leave a native binding that 0.10.0 counted as a live client
+forever, so `acc update` kept reporting `unknown client pid` holds after every session had
+closed. 0.10.1 judges such a binding by its session record and removes it while it prepares
+the update, so the update from 0.9.x finishes once no 0.9.x session runs. From 0.10.0, 0.10.1
+keeps the store contract, so it activates without waiting for open sessions.
+
 ## From 0.8.x
 
 Update as usual:
@@ -383,9 +440,11 @@ Running ACC processes, including idle MCP servers, still publish a hold for as l
 live, and native bindings still hold until observed client SessionEnd cleanup or confirmed
 process death; the vendor daemon can remain running after that lifecycle event. What
 changed is which of those holds keeps an update pending: only one whose declared store
-contract differs from the incoming version's, or that declares none at all. Unknown PIDs
-remain conservative holds until lifecycle cleanup. `acc finish`, presence TTL, and delivery
-off alone still do not prove native end. When a hold does block, close the relevant client
+contract differs from the incoming version's, or that declares none at all. From 0.10.1, a
+binding that names no client process stops holding when its session record is gone, names an
+exited process, or, with no process recorded, is offline: closed, or 30 minutes without a
+heartbeat (#273). For a binding that names its client, `acc finish`, presence TTL, and
+delivery off still do not prove native end. When a hold does block, close the relevant client
 sessions and persistent ACC processes to release it, or accept the eligible Codex service
 maintenance offer in `acc update`. Background updates never request fresh restart consent.
 Hooks never wait for a network download. If integration refresh temporarily prevents

package/docs/WHY_ACC.md

@@ -1,11 +1,17 @@
 # Why ACC
 
-ACC fits a familiar workflow: you open several AI sessions, give each one a task, and keep
-their contexts, permissions, checkouts, and models independent. The missing piece is peer
-awareness. When their work overlaps, they need to ask and answer each other without making
-you carry every sentence between windows.
+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.
 
-Supported integrations provide that awareness and teach agents the coordination interface.
+Each session keeps its own context, permissions, checkout, and model.
+
+Supported integrations make peers visible and teach agents the coordination interface.
 The agents decide whether a dependency or peer is relevant. ACC does not assign tasks or
 promise that every model will coordinate; it gives independent sessions a local, durable
 place to discover peers, ask questions, answer in threads, acknowledge messages, reserve
@@ -15,12 +21,12 @@ resources, and hand off context.
 
 ```mermaid
 flowchart TD
-  A["Do you independently open several sessions?"] -->|no| N["ACC adds little and stays quiet"]
-  A -->|yes| B["Must they keep separate ownership and permissions?"]
+  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?"]
   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"]
-  C -->|no| N
+  C -->|no| N["ACC adds little and stays quiet"]
 ```
 
 The useful result is simple: related tasks proceed without the human acting as a message
@@ -43,9 +49,26 @@ Claims support communication; they are not the product's center. The useful loop
 retrieve, reply, acknowledge, and hand off. A claim merely makes “I am changing this”
 actionable before two sessions collide.
 
+## What hooks add over an MCP server or a script
+
+A model calls an MCP tool only when it decides to: the tool sits in its list, and the session
+remembers it or does not. ACC installs hooks in each supported client, so peers and their
+messages arrive in the turn by themselves, and with live delivery enabled a message can wake a
+session that is not polling for anything. For clients without an integration, ACC offers its
+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
+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
+told how.
+
 ## Choose another layer when
 
-Choose a managed runtime if you want the system to create agents, assign execution state,
+Try the client's own messaging first when every session runs in Claude Code, or every one in
+Codex; Claude Code's also reaches your sessions on other machines. Choose a managed runtime if you want the system to create agents, assign execution state,
 select models, spend token budgets, or control ongoing agent execution. Choose a tracker when
 you need organizational planning. Choose a hosted service when participants must
 coordinate across machines.

package/docs/index.md

@@ -1,7 +1,8 @@
 # ACC documentation
 
-ACC adds peer awareness and communication to AI sessions you open yourself. You continue
-to give each agent ordinary work; supported integrations tell agents about their peers and
+ACC carries questions, reviews and handoffs between AI sessions you open yourself in clients
+from different vendors, such as Claude Code and Codex. You continue to give each agent
+ordinary work; supported integrations tell agents about their peers and
 teach them how to coordinate when it is useful. The agents remain independent, and each
 decides what its task requires.
 
@@ -9,12 +10,13 @@ decides what its task requires.
 
 1. [Getting started](GETTING_STARTED.md) — install ACC, open two sessions, give them related
    tasks, and know what coordination to look for.
-2. [Why ACC](WHY_ACC.md) — decide whether independent peer coordination fits your work.
+2. [Why ACC](WHY_ACC.md) — decide whether your work spans clients from different vendors and
+   needs ACC between them.
 3. [Capabilities](CAPABILITIES.md) — check what your client and platform can actually do.
 4. [Troubleshooting](TROUBLESHOOTING.md) — diagnose missing peers, queued messages, and
    capability fallback.
-5. [Upgrading ACC](UPGRADING.md) — update from 0.4.0, preserve history, refresh integrations,
-   and account for the data-format and inbox-response changes from 0.3.1.
+5. [Upgrading ACC](UPGRADING.md) — update from 0.9.x, whose stores move to contract 7 by
+   themselves, or from an earlier release, and control automatic updates.
 
 ## See it in context
 

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

@@ -1,6 +1,6 @@
 {
   "name": "@agents-can-communicate/adapter-antigravity",
-  "version": "0.9.1",
+  "version": "0.10.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.9.1",
+  "version": "0.10.1",
   "description": "Coordinate this Antigravity CLI session with other AI agent sessions working in the same workspace."
 }

package/node_modules/@agents-can-communicate/adapter-claude-code/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agents-can-communicate/adapter-claude-code",
-  "version": "0.9.1",
+  "version": "0.10.1",
   "private": true,
   "type": "module",
   "exports": {

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

@@ -2,7 +2,8 @@ import { defineAdapter, projectContext, projectContextResult }
   from "@agents-can-communicate/adapter-sdk";
 import certification from "../certification.json" with { type: "json" };
 
-import { denyOutcome, injectOutcome, injectStartOwnerOutcome, normalizeClaudeHook } from "./hooks.mjs";
+import { denyOutcome, failOpenNotice, injectOutcome, injectStartOwnerOutcome, normalizeClaudeHook }
+  from "./hooks.mjs";
 import { MIN_VERSION, PROTOCOL_CONTRACT, bindNativeSession, offerMessage, planNativeActivation,
   probeNativeDelivery, refreshNativeSession, retireNativeSession } from "./inbox-delivery.mjs";
 import { observedInboxDirectories } from "./inbox-observed-directories.mjs";
@@ -110,6 +111,7 @@ export function createClaudeCodeAdapter() {
 
     denyOutcome,
     injectOutcome,
+    failOpenNotice,
     injectStartOwnerOutcome,
     normalizeHook: payload => normalizeClaudeHook(payload),
     renderContext: (sync, options) => projectContext(sync, options),

package/node_modules/@agents-can-communicate/adapter-claude-code/src/hooks.mjs

@@ -120,3 +120,15 @@ export function injectStartOwnerOutcome(context) {
   return { stdout: `${JSON.stringify({ hookSpecificOutput: {
     hookEventName: "SessionStart", additionalContext: context } })}\n`, stderr: "", exitCode: 0 };
 }
+
+/**
+ * A line for the user when a hook fails open for a reason they can act on.
+ *
+ * Claude Code shows a hook's `systemMessage` to the user and never sends it to
+ * the model; a failed-open hook's stderr it shows to no one. Only on a session
+ * start and before a turn, the two hooks whose output a person is reading.
+ */
+export function failOpenNotice({ kind, message }) {
+  if (kind !== "sessionStart" && kind !== "beforeTurn") return null;
+  return JSON.stringify({ systemMessage: message });
+}

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

@@ -1,6 +1,6 @@
 {
   "name": "@agents-can-communicate/adapter-codex",
-  "version": "0.9.1",
+  "version": "0.10.1",
   "private": true,
   "type": "module",
   "exports": {

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

@@ -9,7 +9,7 @@ import { createCodexDiscovery } from "./native-discovery.mjs";
 export { sameMaintenanceIdentity } from "./maintenance.mjs";
 
 import { CODEX_QUEUE_MINIMUM, PROTOCOL_CONTRACT } from "./app-server-client.mjs";
-import { allowOutcome, denyOutcome, injectOutcome, normalizeCodexHook }
+import { allowOutcome, denyOutcome, failOpenNotice, injectOutcome, normalizeCodexHook }
   from "./hooks.mjs";
 import { planCodexInstall, detectCodex, installCodexPlugin, preflightCodexUninstall,
   uninstallCodexPlugin } from "./install.mjs";
@@ -121,6 +121,7 @@ export function createCodexAdapter() {
     denyOutcome,
     allowOutcome,
     injectOutcome,
+    failOpenNotice,
     normalizeHook: payload => normalizeCodexHook(payload),
     renderContext: (sync, options) => projectContext(sync, options),
     renderContextResult: (sync, options) => projectContextResult(sync, options),

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

@@ -160,3 +160,14 @@ export function injectOutcome(context, notice) {
     hookSpecificOutput: { hookEventName: "UserPromptSubmit", additionalContext: context } }),
   stderr: "", exitCode: 0 };
 }
+
+/**
+ * A line for the user when a hook fails open for a reason they can act on: the
+ * hook's `systemMessage`, which Codex shows in the chat and never sends to the
+ * model (0.147.0, 0.155.1 and 0.159.1). Only on a session start and before a
+ * turn, the two events where that display was measured.
+ */
+export function failOpenNotice({ kind, message }) {
+  if (kind !== "sessionStart" && kind !== "beforeTurn") return null;
+  return JSON.stringify({ systemMessage: message });
+}

package/node_modules/@agents-can-communicate/adapter-gemini-cli/extension/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "agents-can-communicate",
-  "version": "0.9.1",
+  "version": "0.10.1",
   "description": "Coordinate this Gemini CLI session with other AI agent sessions working in the same workspace.",
   "contextFileName": "skills/acc/SKILL.md"
 }

package/node_modules/@agents-can-communicate/adapter-gemini-cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agents-can-communicate/adapter-gemini-cli",
-  "version": "0.9.1",
+  "version": "0.10.1",
   "private": true,
   "type": "module",
   "exports": {

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

@@ -1,6 +1,6 @@
 {
   "name": "@agents-can-communicate/adapter-grok",
-  "version": "0.9.1",
+  "version": "0.10.1",
   "private": true,
   "type": "module",
   "exports": {

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

@@ -1,6 +1,6 @@
 {
   "name": "@agents-can-communicate/adapter-kimi",
-  "version": "0.9.1",
+  "version": "0.10.1",
   "private": true,
   "type": "module",
   "exports": {

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

@@ -1,6 +1,6 @@
 {
   "name": "@agents-can-communicate/adapter-sdk",
-  "version": "0.9.1",
+  "version": "0.10.1",
   "private": true,
   "type": "module",
   "exports": {

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

@@ -181,6 +181,12 @@ export function defineAdapter(manifest) {
   if (manifest.inboundSockets !== undefined && typeof manifest.inboundSockets !== "function") {
     usage("optional inboundSockets must be a function", { id: manifest.id });
   }
+  // `failOpenNotice({ kind, message })` renders a line the user sees when a hook
+  // fails open for a reason the user can act on, or returns null. Only a client
+  // whose hook output reaches the user declares it.
+  if (manifest.failOpenNotice !== undefined && typeof manifest.failOpenNotice !== "function") {
+    usage("optional failOpenNotice must be a function", { id: manifest.id });
+  }
   if (manifest.nativeDelivery !== undefined) {
     const client = manifest.client.certificationName ?? manifest.client.command;
     native.nativeDelivery = validateNativeDeliveryContract(manifest.nativeDelivery,

package/node_modules/@agents-can-communicate/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agents-can-communicate/cli",
-  "version": "0.9.1",
+  "version": "0.10.1",
   "private": true,
   "type": "module",
   "exports": {