agents-can-communicate 0.8.0 → 0.8.2

package/bin/entrypoints/acc-mcp.mjs

@@ -54,7 +54,6 @@ await serve({
   context: {
     service,
     deliveryRouter: createDeliveryRouter({ service, adapters, clock,
-      platform: `${process.platform}-${process.arch}`,
       readLivePolicy: ({ adapter }) => readInstalledLivePolicy({ dataHome,
         adapterId: adapter.id }) }),
     workspaceId: descriptor.id,

package/bin/entrypoints/acc.mjs

@@ -25,7 +25,6 @@ const runtime = {
   ids: { next: kind => createId(kind, randomBytes) },
   createDeliveryRouter: ({ service, clock, dataHome }) =>
     createDeliveryRouter({ service, adapters, clock,
-      platform: `${process.platform}-${process.arch}`,
       readLivePolicy: ({ adapter }) => readInstalledLivePolicy({ dataHome,
         adapterId: adapter.id }) }),
   // Asked only by `acc config init`, and only when stdout is a terminal. There

package/docs/ADAPTER_AUTHORING.md

@@ -29,6 +29,7 @@ export function createExampleAdapter() {
     detect, install, uninstall, doctor,
     planInstall,                      // what install would write
     preflightUninstall,               // optional read-only removal validation
+    inboundSockets,                   // optional: socket paths a live sender connects to
     normalizeHook,                    // client payload -> normalised event
     renderContext,                    // SyncResult -> text
     renderContextResult,              // text + ids of complete rendered groups
@@ -81,10 +82,15 @@ is not evidence for compaction. Counts add no ids to `offeredMessageIds` or
 
 `client.command` does double duty. `detect.mjs` uses it as the version-probe binary, and
 presence liveness separately walks the hook's process ancestry for the first ancestor whose
-executable basename matches it, to learn the client's own pid. Declare the binary the client
-actually runs as — `command: "claude"` for a client that really runs as `node` resolves
-nothing, and the failure is silent: the session gets `pid: null` and falls back to reading
-presence by age alone, with nothing telling you why.
+executable basename matches it, to learn the client's own pid. A client shipped as a node
+script, such as Gemini CLI, runs as `node`; for a `node` ancestor the walk also matches the
+script it runs: the first argument after any interpreter options, by basename, with a
+`.js`, `.mjs` or `.cjs` extension ignored. A word right after an option written without `=`
+may be that option's value (`--require ./preload.cjs`), so it is also tried and the script
+after it still counts. Declare the name the client actually runs as. A
+command that matches neither resolves nothing, and the failure is silent: the session gets
+`pid: null`, falls back to reading presence by age alone, and is not pinned to its
+generation, with nothing telling you why.
 
 ## Declare only proven capabilities
 
@@ -148,9 +154,8 @@ to its capabilities:
 
 ```js
 nativeDelivery: {
-  minimumByPlatform: { "darwin-arm64": "2.1.282" },
-  anchors: [{ platform: "darwin-arm64", version: "2.1.282",
-    protocolContract: "claude-code-inbox-socket-v1" }],
+  minimum: "2.1.282",
+  anchors: [{ version: "2.1.282", protocolContract: "claude-code-inbox-socket-v1" }],
   knownBad: [],
   activationKinds: ["native-service"],
   offerKind: "wake",
@@ -159,17 +164,32 @@ nativeDelivery: {
 
 The rules `defineAdapter` enforces, and the ones the runtime applies:
 
-- A minimum is the **first passing capture** on that platform, never a guessed first vendor
-  release. Every anchor must have passing `delivery.livePush` evidence for the same client,
-  version, and platform, and each minimum must itself be an anchor.
-- There is intentionally **no maximum version**. A newer stable release is admitted only
-  when a current read-only feature probe (`probeNativeDelivery()`) and a per-session
-  handshake (`bindNativeSession()`) both report the anchored `protocolContract`;
-  `evaluateNativeEligibility()` and `validateNativeHandshake()` are those two checks.
-- Prereleases require their own passing capture; they are `prerelease_not_captured` even
-  when numerically newer. `knownBad` names exact versions or inclusive intervals.
-- Exact-version certification still governs every non-native capability;
+- The minimum is the **first passing capture**, never a guessed first vendor release. Every
+  anchor must have passing `delivery.livePush` evidence for the same client and version, and
+  the minimum must itself be an anchor. The platform an evidence row names is where the
+  capture was taken; it is provenance, and the anchor names no platform.
+- There is intentionally **no maximum version** and **no platform**. A newer release is
+  admitted, on every platform, only when a current read-only feature probe
+  (`probeNativeDelivery()`) and a per-session handshake (`bindNativeSession()`) both report
+  the anchored `protocolContract`; `evaluateNativeEligibility()` and
+  `validateNativeHandshake()` are those two checks.
+- A prerelease is judged by its release triple, as hook capabilities are: `2.2.0-beta.1` is
+  `2.2.0` against the minimum and `knownBad`. `knownBad` names exact versions or inclusive
+  intervals. A version that cannot be read at all is `version_unavailable`.
+- Certification evidence still governs every non-native capability;
   `effectiveCapabilities()` is unchanged. The native rule is used for live delivery alone.
+
+What may refuse live delivery is exactly three things:
+
+- the machine's own probe or per-session handshake failing;
+- a client older than the first passing capture;
+- a regression recorded in `knownBad`.
+
+Nothing else: not the platform, not a prerelease suffix, not where the evidence was taken. A
+transport that is technically different on some platform is the probe's fact to report, as
+`native_delivery_unsupported`, never a gap in the captures. The 0.8.0 shape,
+`minimumByPlatform` with a platform on each anchor, is refused by name; the design record is
+`docs/design/2026-09-26-native-delivery-across-platforms.md` in the repository.
 - Native methods return closed facts (`validateNativeActivationPlan()` closes the
   activation plan) and never put vendor data - endpoints, sockets, raw errors - into core.
 
@@ -208,6 +228,19 @@ the refreshed lease. Refresh is not a heartbeat and cannot extend presence beyon
 its own expiry. Optional `retireNativeSession()` cleans adapter-owned endpoint state
 after confirmed core retirement; it must remain bounded and fail open for hooks.
 
+An adapter whose `offerMessage()` connects to a Unix socket in the recipient's session
+declares where those sockets live with the optional `inboundSockets(context)`. It returns
+absolute paths, directories or sockets, derived from `context.env`, `context.platform` and
+the client homes in the context. It runs synchronously, once per install, doctor or refresh
+command, and must never throw. It may read the adapter's own records under
+`context.stateRoot` when a session can bind outside what the environment implies. Claude Code
+reads its endpoint records there, and keeps each read bounded. The installer
+composes every known adapter's declaration into `context.receiverSockets`. An adapter whose
+client sandboxes the sender's shell allows exactly that list, and reports its outgoing
+permissions configured only while every entry is allowed. It never names another vendor's
+paths itself. Codex does this in its permission profile. Declare a new receiving transport
+here, or every Codex sender gets `transport_permission_denied` against it.
+
 A package-shipped passing Codex installed-hook capture additionally references its
 complete real product matrix through the selected provenance record's
 `productEvidence: { fixture, sha256 }`. Package verification checks the actual file,

package/docs/ARCHITECTURE.md

@@ -107,8 +107,9 @@ turn.
 
 The Claude Code inbox wake has installed-client evidence on 2.1.282. Codex LocalDaemon
 has it on 0.152.1 and 0.153.4. Antigravity CLI has it on 1.2.7 and later through a relay
-the agent starts in its own shell. All three use a captured platform minimum,
-current probe and exact session handshake. Claude Code and Codex preserve the ordinary
+the agent starts in its own shell. All three use a captured minimum that applies on every
+platform, a current probe and an exact session handshake; a prerelease is judged by its
+release triple. Claude Code and Codex preserve the ordinary
 client launch. Claude Code verifies its session registry, and Codex verifies its registered
 thread and workspace. Native delivery owns no vendor daemon lifecycle. Gemini CLI and Kimi
 Code have exact-version next-turn evidence only. Grok and generic MCP use inbox polling.
@@ -226,10 +227,12 @@ modes. It preserves explicit declarations and does not rewrite live leases. Miss
 changed generation files and unknown native bindings remain unverified holds.
 A session is also pinned to the generation
 it started with: its hooks delegate to that generation while the pin declares the same
-store contract this one does, and run the active generation otherwise. A generation
-directory is reclaimed once no control pointer, live lease, live pin or staging hold names
-it. Parsed help, version, and update recovery remain available when workspace admission is
-unavailable.
+store contract this one does, and run the active generation otherwise. Apart from
+`SessionEnd`, only the client's confirmed death releases a pin, so a session whose client
+process cannot be found is not pinned, and a pin that names no client is reaped. A
+generation directory is reclaimed once no control pointer, live lease, live pin or staging
+hold names it. Parsed help, version, and update recovery remain available when workspace
+admission is unavailable.
 
 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.

package/docs/CAPABILITIES.md

@@ -20,9 +20,9 @@ Capability honesty separates four questions that are easy to collapse:
 A source method or vendor documentation is not certification. A capture applies forward: from
 the version that recorded it until a later capture changes that capability, and to every
 platform until one of them records something of its own. A client older than every capture
-degrades to false, and so does a capability a capture recorded as failing. Native
-minimum-based eligibility is separate, and stays per-platform. No weaker session inherits a
-stronger peer's capability.
+degrades to false, and so does a capability a capture recorded as failing. Native live
+delivery reads its captured minimum the same way: on every platform, with a prerelease judged
+by its release triple. No weaker session inherits a stronger peer's capability.
 
 Run `acc doctor` in the project when observed behavior differs from this page. It reports
 the installed client version, platform, effective capability, and fallback instead of
@@ -53,18 +53,27 @@ The native rows are `no` at the hook versions this matrix names.
 Separate installed-client captures establish Codex `livePush` on 0.152.1 and
 0.153.4, Claude Code `livePush` on 2.1.282 through the session inbox, and
 Antigravity CLI `livePush` on 1.2.7 and later through a relay the agent starts in its own shell.
-Native eligibility uses the captured platform minimum, a current feature probe,
-and an exact per-session handshake. It is experimental and requires recipient
-opt-in. Codex, Claude Code and Antigravity CLI reply through `acc reply`. Their native
+Native eligibility uses the captured minimum, a current feature probe, and an exact
+per-session handshake. It is experimental and requires recipient opt-in.
+
+What may refuse live delivery is exactly three things:
+
+- the machine's own probe or per-session handshake failing;
+- a client older than the first passing capture;
+- a regression recorded in `knownBad`.
+
+Nothing else: not the platform, not a prerelease suffix, not where the evidence was taken.
+A platform whose transport is technically different is refused by the probe as a fact about
+that transport, which is what Claude Code's named pipe on native Windows is. Codex, Claude Code and Antigravity CLI reply through `acc reply`. Their native
 `replyRoute` remains false.
 
 The limitations belong next to the adapters they affect:
 
 | Adapter | Exact limitation and evidence |
 |---|---|
-| Antigravity CLI | 1.2.7 on darwin-arm64, captured in print mode, and every later release by the forward rule. Only `SessionStart`, `PreInvocation`, `PostInvocation` and `Stop` load; `SessionEnd`, `PreToolUse` and `PostToolUse` are accepted into the config file and silently dropped, so there is no tool guard and no session-end deregistration - a session goes offline by presence age or an explicit `acc finish`. Payloads carry no `hook_event_name`, so each registered command passes its own event name. The end-of-turn `Stop` continuation reaches the model and is a bounded nudge, not a gate: ACC continues a turn at most once and fails open, and the client caps consecutive continuations itself (vendor 1.1.9). `agy agentapi send-message` can wake an idle session - captured - but only with that session's language-server address and CSRF token, which exist in the agent's own shell and in no hook. ACC does not take that token, so live push and reply routing are false. A peer message that arrives while the model writes its last answer is carried by the `Stop` continuation instead. A write that parses can register nothing, so install and doctor read `agy -p "/hooks"` back instead of trusting the file. Live push (1.2.7, darwin-arm64, TUI only, experimental, recorded opt-in) runs through a relay the agent starts once per conversation from its own shell - the only process holding the session endpoint - after ACC's context asks it to, up to three times while none is serving; the operator approves that command at the client's permission prompt. An idle session wakes; a busy one sees the message after its running answer, or at the next model invocation when the turn waits on a tool. Print mode and the first session in a folder trusted at that launch get no relay. |
+| Antigravity CLI | 1.2.7 on darwin-arm64, captured in print mode, and every later release by the forward rule. Only `SessionStart`, `PreInvocation`, `PostInvocation` and `Stop` load; `SessionEnd`, `PreToolUse` and `PostToolUse` are accepted into the config file and silently dropped, so there is no tool guard and no session-end deregistration - a session goes offline by presence age or an explicit `acc finish`. Payloads carry no `hook_event_name`, so each registered command passes its own event name. The end-of-turn `Stop` continuation reaches the model and is a bounded nudge, not a gate: ACC continues a turn at most once and fails open, and the client caps consecutive continuations itself (vendor 1.1.9). `agy agentapi send-message` can wake an idle session - captured - but only with that session's language-server address and CSRF token, which exist in the agent's own shell and in no hook. ACC does not take that token, so live push and reply routing are false. A peer message that arrives while the model writes its last answer is carried by the `Stop` continuation instead. A write that parses can register nothing, so install and doctor read `agy -p "/hooks"` back instead of trusting the file. Live push (1.2.7, darwin-arm64, TUI only, experimental, recorded opt-in) runs through a relay the agent starts once per conversation from its own shell - the only process holding the session endpoint - after ACC's context asks it to, up to three times while none is serving; the operator approves that command at the client's permission prompt. An idle session wakes; a busy one sees the message after its running answer, or at the next model invocation when the turn waits on a tool. Print mode and the first session in a folder trusted at that launch get no relay. The client asks before every shell command (1.2.12), so install always adds the prefix rule `command(<wrapper>)` to the client's settings to let the woken agent's ACC commands run without that prompt. A woken session answered with no prompt under that rule on 1.2.12 (2026-09-28); print mode with it has not been captured. |
 | Codex | Next-turn context, captured on 0.147.0, requires plugin trust. The observed stock 0.153.4 upgrade from ACC 0.3.1 to 0.4 required fresh review of five modified hook definitions; a subsequent restart retained all five active (activation evidence, not new event certification). LocalDaemon native delivery was captured through the installed package on 0.152.1 and 0.153.4, darwin-arm64; minimum 0.152.1, recorded opt-in, current feature probe and exact thread/cwd/process/version/protocol checks are required. Ordinary launch preserves the receiver workspace without ACC arguments or daemon ownership. Embedded or unreachable sessions keep their inbox. Native `replyRoute` remains false. |
-| Claude Code | 2.1.233 next-turn delivery waits for the next user prompt. From 2.1.282 on darwin-arm64, `delivery.livePush` is a live capability behind the native contract (experimental, off until opted in). ACC wakes the session through the inbox socket that Claude Code opens for every session, with one line of fixed ACC text and the message id. An idle session starts a turn. A busy session takes the wake between two tool calls. Each delivered wake fires `UserPromptSubmit`, so the next-turn hook shows the body and records the receipt `offered` via `next-turn`. The model answers with `acc reply`, so `delivery.replyRoute` stays false. A session in `bypassPermissions` mode holds each wake for approval unless `crossSessionInbound` is `accept`, and `refuse` drops wakes. Native Windows keeps next-turn delivery: its inbox is a named pipe that requires an auth line, and it is uncaptured. Linux is uncaptured. |
+| Claude Code | 2.1.233 next-turn delivery waits for the next user prompt. From 2.1.282, captured on darwin-arm64 and applied on every platform whose inbox is a Unix socket, `delivery.livePush` is a live capability behind the native contract (experimental, off until opted in). ACC wakes the session through the inbox socket that Claude Code opens for every session, with one line of fixed ACC text and the message id. An idle session starts a turn. A busy session takes the wake between two tool calls. Each delivered wake fires `UserPromptSubmit`, so the next-turn hook shows the body and records the receipt `offered` via `next-turn`. The model answers with `acc reply`, so `delivery.replyRoute` stays false. A session in `bypassPermissions` mode holds each wake for approval unless `crossSessionInbound` is `accept`, and `refuse` drops wakes. Native Windows keeps next-turn delivery: its inbox is a named pipe that requires an auth line, and it is uncaptured. Linux is uncaptured. |
 | Gemini CLI | Package-shipped next-turn certification starts at 0.57.0. Its TUI has no captured external wake or queue interface and `--acp` changes launch ownership, so native delivery is fallback-only; live push and reply routing remain false. |
 | Grok | The Grok 1.0.24 installed-client check observed own CLI arguments after a terminal result, followed by owned work, message, and finish calls. This identity-only path does not certify peer-context injection. Documentation-shaped payloads do not count as real captures. The public leader surface exposed no proven addressed injection into an ordinary TUI session, so native delivery is `awaiting_compatibility_capture`; all capabilities remain false. |
 | Kimi Code | Next-turn and guard evidence was captured on 0.36.1, plus a 60-second heartbeat. Its server/queue APIs do not prove a transparent binding to an independently opened session, so native delivery is fallback-only. |
@@ -93,10 +102,11 @@ demand without a client heartbeat. Retirement is final: neither route may revive
 retired binding, a closed session or an old generation. Delivery lease refresh does
 not renew participant presence.
 
-On darwin-arm64, Codex LocalDaemon, the Claude Code inbox wake and the Antigravity CLI
-relay have captured experimental live delivery. Other adapters retain their separately
-certified next-turn paths or inbox polling. Linux and other uncaptured platforms retain
-the durable inbox; these captures establish no new hook capabilities there.
+Codex LocalDaemon, the Claude Code inbox wake and the Antigravity CLI relay have captured
+experimental live delivery, on darwin-arm64. Those captures set the minimum that applies on
+every platform; on a host they never named, the probe and the per-session handshake decide,
+and a transport that does not answer keeps the durable inbox. Other adapters retain their
+separately certified next-turn paths or inbox polling.
 
 Codex's 120-second delivery lease can refresh on demand for the same live endpoint;
 it does not extend the 24-hour participant presence limit. A TUI exit can leave its
@@ -116,8 +126,8 @@ policy:
 | `all` | every addressed message kind may use live push |
 
 The default is `off`. `acc install --delivery actionable|all` records recipient consent.
-Current activation remains off when the platform, captured minimum or feature probe
-does not qualify; that temporary failure does not erase the requested policy. Each
+Current activation remains off when the captured minimum or the feature probe does not
+qualify; that temporary failure does not erase the requested policy. Each
 session must pass its own generation-bound handshake. Every adapter reads consent from the
 installation record and rereads it at hooks and before offers, so a long-running vendor
 process cannot retain permission through an old binding snapshot.

package/docs/CLI.md

@@ -104,9 +104,23 @@ got. Two sessions of one participant show the same numbers, so read the workspac
 `<n> offered, not retrieved` when that number is above zero. Offered is not read: a
 transport took the bytes, and the model may or may not have looked.
 
-A participant with no open session is left out, unless messages still wait for it. Then its
-latest session stays listed as `offline`, with `endReason` when the client said why the
-session ended, such as `"clear"` for Claude Code's `/clear`. The text line names each one:
+A session is `stale` when no turn has sent a heartbeat for three heartbeat cadences. Each
+session row says what a message to such a session meets. `processTracked` is true when ACC
+knows the client process. A dead process makes the session `offline`, so a stale session with
+a tracked process is idle. `liveDelivery` is true when the session has a live delivery
+binding, and `liveLeaseCurrent` says whether the binding's lease is still valid. A stale
+session wakes on send when the lease is valid, or when its adapter can verify the receiver
+again: the router does that for a lapsed lease before it offers. The text line counts stale
+sessions by that result:
+`5 live (2 idle, wake on send; 1 idle until next turn; 1 idle, inbox only)`. `not answering`
+is kept for a stale session whose process ACC does not know.
+
+A participant with no open session is left out, unless messages still wait for it: queued,
+or offered by a live transport and not yet shown again, so that its next turn would show
+them. A message the next-turn hook already showed does not wait, since nothing will reach the
+participant for it again. A waiting participant's latest session stays listed as `offline`,
+with that number as `waiting`, and with `endReason` when the client said why the session
+ended, such as `"clear"` for Claude Code's `/clear`. The text line names each one:
 `waiting for a closed session: claude_code-b (cleared, 2)`. `acc status --all` lists every
 session. Default `sync` reads
 events after a 16-digit event cursor (100 by
@@ -370,6 +384,11 @@ Your existing npm or Homebrew command and shell profiles remain unchanged.
 An older consent that covered service start receives one expanded choice for the download.
 An accepted or declined answer persists. To change a declined answer, use
 `acc install --adapter codex --delivery actionable` (or `all` for that policy).
+Installing the Antigravity adapter always adds one prefix rule for ACC's wrapper to
+`~/.gemini/antigravity-cli/settings.json`, so ACC's commands run there without an approval
+prompt; nothing asks about it and the delivery policy does not change it. Uninstall removes
+exactly that rule. See
+[Antigravity CLI command approval](CONFIGURATION.md#antigravity-cli-command-approval).
 Explicit `--delivery actionable|all` also approves a required download on supported clients.
 Dry runs, delivery off, doctor, automatic refresh, and message delivery do not download
 Codex or start its service. Uninstall does not remove Codex or stop the shared vendor daemon.

package/docs/CONFIGURATION.md

@@ -131,8 +131,9 @@ The allowed values are `off`, `actionable`, and `all`; the default is `off`. Thi
 does not belong in `acc.workspace.json`, where a pull request could opt someone else into
 spending a turn. It also cannot create a capability. Every adapter reads live-delivery
 consent from this installation record, and only from it. Exact-version evidence governs
-ordinary hook features. Claude Code live delivery separately requires macOS arm64, version
-2.1.282 or newer, and a current feature probe before installation applies the requested
+ordinary hook features. Claude Code live delivery separately requires version 2.1.282 or
+newer on macOS or Linux (on native Windows its inbox is a named pipe, so delivery stays
+next-turn), and a current feature probe before installation applies the requested
 policy. If those install-time checks fail, effective policy remains `off` and the installer
 reports next-turn or inbox fallback. Each later session must also pass its own
 generation-bound handshake. A failed session handshake clears or refuses that binding and
@@ -146,7 +147,7 @@ each wake for your approval unless its `crossSessionInbound` setting is `accept`
 never overrides them. See
 [held or dropped wakes](TROUBLESHOOTING.md#a-claude-code-session-holds-or-drops-acc-wakes).
 
-Codex LocalDaemon delivery separately requires macOS arm64, Codex 0.152.1 or newer, a
+Codex LocalDaemon delivery separately requires Codex 0.152.1 or newer, a
 current feature probe, and exact thread, canonical cwd, process, version and protocol
 checks. On Codex 0.154.0 or newer, explicit complete setup can download a missing matching
 standalone package and prepare a definitely absent service. The setup choice names the
@@ -160,15 +161,47 @@ Unavailable or ineligible sessions retain durable inbox fallback. Use
 ### Codex outgoing permissions
 
 Receiving a native message and sending from the agent's sandbox are separate operations.
-On Codex 0.153.4 or newer on macOS arm64, live opt-in also configures outgoing access
+On Codex 0.153.4 or newer, live opt-in also configures outgoing access
 for default workspace permissions. This happens even when the daemon is not yet available.
 Installation, its preview, and the interactive consent question disclose this change.
 
 ACC selects a permission profile named `acc-workspace`, extending `:workspace`. It grants
-write access to the ACC state directory and allows only the local ACC channel directory
-(`/tmp/acc-ch-<uid>`) and the Codex home control socket. The profile enables networking
-through `features.network_proxy = true`, with no external domains allowed. The proxy and
-socket grants must stay together: enabling networking without the proxy changes its scope.
+write access to the ACC state directory and allows only the Unix sockets ACC delivers to.
+Each receiving adapter declares its own, and the profile lists all of them even when an
+install names Codex alone:
+
+| Receiver | Allowed path |
+|---|---|
+| Codex | the control socket, `<CODEX_HOME>/app-server-control/app-server-control.sock` |
+| Antigravity CLI relay | the ACC channel directory, `/tmp/acc-ch-<uid>` on macOS |
+| Claude Code inbox | `/tmp/cc-socks`, `/tmp/cc-socks-<uid>`, `$XDG_RUNTIME_DIR/cc-socks` or else `$CLAUDE_CODE_TMPDIR/cc-socks` when set, `/run/user/<uid>/cc-socks` on Linux, and the directory of every Claude Code inbox ACC has bound on this machine |
+
+ACC writes each path with its existing parent resolved, so on macOS the entries read
+`/private/tmp/...`. Codex resolves a granted path only if it exists when Codex builds the
+sandbox policy, and the sandbox compares resolved paths: a `/tmp/cc-socks-<uid>` entry
+written before that directory existed never matched. A socket that is a link, such as the
+Codex control socket, keeps its own name.
+
+A command in the Codex sandbox can therefore connect to any of your Claude Code sessions'
+inbox sockets. Claude Code's own inbound settings still decide what a received frame may do,
+and ACC checks Claude Code's session registry before each wake it sends.
+
+The profile enables networking through `features.network_proxy = true`, with no external
+domains allowed. The proxy and socket grants must stay together: enabling networking
+without the proxy changes its scope.
+
+Doctor reports outgoing delivery as configured only while the profile allows every socket
+above. A profile that ACC 0.8.0 or 0.8.1 wrote lacks the Claude Code inbox directories;
+doctor names the missing paths and `acc install --adapter codex`. That command and
+`acc update` rewrite ACC's own profile under the recorded delivery policy, `off` included.
+Start a new Codex session afterwards.
+
+The environment variables above are read from the process that runs `acc install` or
+`acc doctor`. A Claude Code session started with its own `CLAUDE_CODE_TMPDIR` or
+`XDG_RUNTIME_DIR` binds its inbox elsewhere. ACC learns that directory when its hooks first
+bind the session, from its own endpoint record. From then on doctor names the directory
+until `acc install --adapter codex` or `acc update` adds it. Only a directory named as Claude
+Code names its inboxes, `cc-socks` or `cc-socks-<uid>`, is taken from a record.
 
 An existing legacy workspace-write configuration is migrated only when its sole writable
 root is ACC's state directory. Custom permission/configuration profiles, additional roots,
@@ -184,6 +217,38 @@ generated permission component is unchanged.
 If any component was edited or another setting depends on it, ACC preserves the entire
 bundle and reports it for review. Plugin registration can still be removed independently.
 
+### Antigravity CLI command approval
+
+Antigravity CLI asks for approval before each shell command, ACC's included. A session that
+live delivery wakes while you are away would therefore stop at the agent's first ACC command,
+and the peer would get no answer until someone approved it. So when `acc install` installs
+the Antigravity adapter, it always adds one rule to the client's own settings:
+
+```text
+~/.gemini/antigravity-cli/settings.json
+  permissions.allow: command(<home>/.gemini/config/acc/acc-cli.sh)
+```
+
+A one-word rule is a prefix: every command that starts with that path runs without asking.
+The agent then runs every ACC command without asking you, including one a peer's message
+prompts; every other command still asks. Install does not ask about the rule, and the
+delivery policy does not change it: it is part of ACC's Antigravity integration, as its hooks
+are.
+
+ACC keeps every other key and rule in the file, leaves a rule you already had as yours, and
+records what it added in its own data home. `acc uninstall` removes every copy of that rule (one
+in the same words cannot be told from ACC's), and a
+container or file ACC created only if nothing else is in it. A rule removed by hand comes back
+at the next `acc install` or automatic refresh; uninstall is what keeps it out. A file that is
+not valid JSON, or whose `permissions.allow` is not a list, is left as it is and reported. The
+client reads the file when it starts, so restart `agy` after install.
+
+The rule matches only a command whose first word is the path without quotes, so ACC's skill
+for this client writes the path without quotes. When your home path contains a space or a
+shell metacharacter, the path needs quotes, no rule can match it, and ACC adds none.
+`acc doctor` reports the rule as present, absent, or unable to apply, and asks for
+`acc install --adapter antigravity` when ACC's rule is missing.
+
 ## Override local paths and identity
 
 Nothing in `acc.workspace.json` says where state is stored, and nothing there can — that is

package/docs/GETTING_STARTED.md

@@ -43,7 +43,7 @@ session after that review; changed hook definitions may require trust again.
 
 For Codex live delivery, follow the outgoing-permission and local-service instructions
 from install/doctor, then start a new session. Default workspace permissions can be
-configured automatically on Codex 0.153.4 or newer on macOS arm64. Custom settings are
+configured automatically on Codex 0.153.4 or newer. Custom settings are
 preserved; see [outgoing permissions](CONFIGURATION.md#codex-outgoing-permissions).
 With legacy sandbox settings, the named ACC state directory must also be in
 `sandbox_workspace_write.writable_roots` in the config the installer identifies.
@@ -58,7 +58,7 @@ hooks wherever the client is at or after a captured version.
 An interactive install asks one default-No question for all selected clients that need a
 choice. Use `--delivery actionable|all` for explicit noninteractive consent. Use
 `--delivery off` to disable incoming automatic requests. A dry run does not ask, write
-configuration, download Codex, or start a service. On macOS arm64 with Codex 0.154.0 or newer,
+configuration, download Codex, or start a service. On macOS or Linux with Codex 0.154.0 or newer,
 the choice includes downloading a missing standalone package from OpenAI. ACC selects the
 matching version and keeps your existing npm or Homebrew command and shell profiles.
 When supported Codex service preparation succeeds, it
@@ -150,7 +150,10 @@ infrastructure, recorded opt-in, and a verified session. Supported explicit setu
 prepare a missing service. Start the client with your normal command. A loaded daemon thread can receive
 messages after its terminal exits. Antigravity CLI 1.2.7 and later has one too: with delivery enabled,
 ACC's context asks the agent to start a relay from its own shell, up to three times while
-none is running, and you approve that command at the client's prompt.
+none is running, and you approve that command at the client's prompt. Antigravity also asks
+before each shell command, so install adds a rule that lets ACC's own commands run without
+that prompt, and a woken session can answer while you are away; see
+[Antigravity CLI command approval](CONFIGURATION.md#antigravity-cli-command-approval).
 [Capabilities](CAPABILITIES.md) explains policy, versions and fallback.
 
 Delivery evidence is deliberately narrow: `queued -> offered -> retrieved -> acknowledged`.

package/docs/HOW_IT_WORKS.md

@@ -123,7 +123,9 @@ All recipients have the same durable record, but adapters expose different accel
   endpoint exists only in the agent's own shell, so ACC's context asks the agent once per
   conversation to start a relay; the user approves that command. The relay keeps the endpoint
   in memory, wakes an idle session with a fenced peer message, holds one for a busy session,
-  and ends with the client. It is experimental, off by default, and can spend tokens.
+  and ends with the client. It is experimental, off by default, and can spend tokens. The
+  woken agent's ACC commands run without the client's approval prompt because install adds
+  one allow rule for ACC's wrapper.
 
 Grok, generic MCP, unsupported versions and uncaptured platforms use inbox polling.
 [Capabilities](CAPABILITIES.md) lists evidence and fallback.

package/docs/PROTOCOL.md

@@ -316,8 +316,8 @@ The recipient owns `livePolicy` because native push may start a model turn:
 
 Default is `off`. Policy never creates a capability. The router requires one
 current eligible recipient generation, supported client evidence, a verified
-binding and adapter acceptance. The Claude Code inbox wake uses a captured 2.1.282
-minimum on darwin-arm64. Its binding requires the same pid and socket in Claude Code's
+binding and adapter acceptance. The Claude Code inbox wake uses a 2.1.282 minimum,
+captured on darwin-arm64 and applied on every platform. Its binding requires the same pid and socket in Claude Code's
 session registry, and every refresh and wake also requires the same session id. Codex LocalDaemon uses a 0.152.1 minimum, confirmed
 through installed-product captures on 0.152.1 and 0.153.4. Recorded consent and
 exact thread, cwd, process, version and protocol verification govern every Codex session.

package/docs/RELEASING.md

@@ -1,8 +1,8 @@
 # Releasing
 
 Use this procedure to build one auditable npm artifact, verify that exact tarball, and keep
-its evidence tied to the commit that supplied its bytes. The package is currently `0.5.0`;
-the commands derive the version from `package.json` so the filename cannot drift.
+its evidence tied to the commit that supplied its bytes. The commands derive the version
+from `package.json` so the filename cannot drift.
 
 ```mermaid
 graph LR
@@ -118,8 +118,10 @@ work belongs under `Unreleased` and gets a new candidate record.
 ## Capture only capabilities you observed
 
 Run native real-client checks on the exact versions and platforms recorded in
-retained fixtures. Exact-version evidence governs normal-turn and guard behavior.
-The Claude Code inbox wake uses its captured macOS arm64 minimum plus a current probe and
+retained fixtures. A capture records evidence, and it never gates beyond that floor: what it
+proves applies from its version onward and on every platform, and what refuses a client is
+the machine's own probe or handshake, an older client, or a recorded regression.
+The Claude Code inbox wake uses its captured minimum plus a current probe and
 per-session handshake. Its passing capture is a real-client product run of the packed
 candidate, launched with the ordinary command and installed hooks. Codex LocalDaemon
 uses a separate 0.152.1 minimum with installed-product captures on 0.152.1 and

package/docs/SECURITY_MODEL.md

@@ -94,12 +94,22 @@ user's: a session in `bypassPermissions` mode holds each wake for approval unles
 `crossSessionInbound` is `accept`, and `refuse` drops wakes.
 
 On captured Codex/macOS configurations, live opt-in also grants outgoing access to ACC's
-state and local Unix sockets through a deny-by-default network proxy. Custom permission
+state and local Unix sockets through a deny-by-default network proxy. The sockets are the
+ones ACC delivers to, which include the directories where Claude Code binds each session's
+inbox: a command in the Codex sandbox can connect to those sockets, and Claude Code's own
+inbound settings decide what a received frame may do. Custom permission
 policies remain user-owned. Selection, proxy and grants are restored together only while
 unchanged; edited or newly referenced settings remain intact. See
 [Codex outgoing permissions](CONFIGURATION.md#codex-outgoing-permissions). Configuration
 readiness does not prove that an active session's overrides permit a live offer.
 
+Antigravity CLI asks before each shell command. Installing its adapter adds one prefix rule
+to that client's `permissions.allow`, for ACC's own wrapper path only. The agent then runs
+every ACC command without a prompt, including one that a peer's message prompts. Every other
+command still asks. ACC records the one rule it added and uninstall removes only that rule.
+It never writes a settings file that it cannot parse. See
+[Antigravity CLI command approval](CONFIGURATION.md#antigravity-cli-command-approval).
+
 ## Claims
 
 CLI claims default to advisory. Guarded enforcement must be requested explicitly and
@@ -175,6 +185,7 @@ caller chooses to send. The sender remains responsible for that content.
 | Symlink or traversal escapes a managed root | Per-segment containment, no-follow reads, closed config schema | Host filesystem compromise is out of scope |
 | Claim denial of service | Leases, visible owner, explicit authority release | Deliberate abuse by a trusted local peer is social |
 | Installer removes user configuration | Content-hashed ownership and byte comparison | User must remove modified leftovers manually |
+| Peer message leads an Antigravity agent to run ACC commands unasked | Allow rule scoped to ACC's wrapper; every other command still asks; uninstall removes it | A peer can still prompt ACC actions, such as a reply or a claim, that nobody approves one by one |
 | False delivery claim | Record-first order, transport-owned `offered`, recipient-owned retrieval/ack, mutation tests | Crash after offer before commit can cause duplicate display |
 | Native endpoint leaks | Ephemeral opaque reference, user-only local endpoint, status redaction | Same-user local processes are outside the trust boundary |
 | MCP client impersonates another session | Identity fixed by launch env, closed tool schemas | A compromised launch config already controls that client |

package/docs/TROUBLESHOOTING.md

@@ -138,8 +138,16 @@ client-owned hook and trust review.
 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.
-On Codex 0.153.4 or newer on macOS arm64, rerun `acc install --adapter codex` with existing
+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:
+the Codex profile did not allow Claude Code's inbox directories, and doctor still reported it
+configured. Doctor now names the missing paths. `acc install --adapter codex` or `acc update`
+rewrites the profile; start a new Codex session so it runs under the new one.
+A Claude Code session started with its own `CLAUDE_CODE_TMPDIR` or `XDG_RUNTIME_DIR` binds its
+inbox outside the directories your shell's environment implies. After ACC first binds that
+session, doctor names its directory. Run `acc install --adapter codex` again, then start a new
+Codex session.
 Doctor's `outgoingDelivery` reports the installed permission configuration separately
 from `nativeDelivery.runtime`: an active receiving channel does not establish outgoing
 access. Custom policies and active-session overrides remain unverified; inspect the config
@@ -240,8 +248,8 @@ local socket permissions as well; a writable state directory alone is insufficie
 ## Gemini does not guard a write
 
 Default and `plan` modes expose no write tool to the model. `auto_edit` exposes edit tools;
-shell availability depends on approval mode. Only Gemini CLI 0.57.0 on `darwin-arm64` has
-package-shipped delivery certification; other versions still use inbox.
+shell availability depends on approval mode. Gemini CLI next-turn delivery is certified from
+0.57.0 onward, on every platform; an older client still uses inbox.
 
 From 0.55 onwards there is a quieter cause with the same symptom: an untrusted folder. The
 client prints `Approval mode overridden to "default" because the current folder is not
@@ -301,10 +309,11 @@ agy -p "/skills" --output-format json
 
 An agent that receives a peer message in print mode (`agy -p`) cannot answer it on its own.
 It forms the right `acc reply` command from the skill, and print mode denies every command
-because it cannot ask for approval; the client says so on stderr. The TUI asks instead.
-ACC does not grant itself that permission. To let headless agents answer, allow the ACC
-command yourself under `permissions.allow` in the client's settings, in the `command(...)`
-form its message names.
+because it cannot ask for approval; the client says so on stderr and names
+`permissions.allow` in its settings. The TUI asks instead. The one rule ACC's install adds
+there is described in
+[Antigravity CLI command approval](CONFIGURATION.md#antigravity-cli-command-approval); it was
+captured in the TUI, and print mode with it has not been captured.
 
 ## Antigravity never wakes while idle
 
@@ -322,6 +331,24 @@ Live delivery needs four things, and `acc doctor` shows each:
 active. A relay ends with its client; nothing is left running after the TUI exits or after
 `acc uninstall`.
 
+## Antigravity wakes and never answers
+
+A woken session that stops at an approval prompt answers only once someone approves its
+first ACC command. `acc doctor` prints an `Antigravity CLI inbound:` line with what it found in
+`~/.gemini/antigravity-cli/settings.json`:
+
+- **No rule.** Each ACC command waits for approval. ACC's install writes the rule, so it was
+  removed since or the install did not reach this file: run `acc install --adapter antigravity`,
+  then restart `agy`. Doctor lists this under what to run next.
+- **The rule is present.** The client reads it at startup, so a session started before it was
+  added still asks; restart `agy`. If a prompt still appears, check the command the agent
+  ran: a path in quotes, or a command wrapped in `sh -c`, matches no rule.
+- **The rule cannot apply.** The path to ACC's wrapper contains a space or a shell
+  metacharacter, so it needs quotes, and a quoted first word matches no rule. ACC adds no
+  rule and approvals stay manual.
+- **The file cannot be read.** ACC leaves an invalid `settings.json` as it is. Repair it, then
+  run `acc install --adapter antigravity` again.
+
 ## Grok shows no injected message
 
 Grok discards UserPromptSubmit context. On the observed 1.0.24 client, run public