agents-can-communicate 0.8.5 → 0.9.1

package/README.md

@@ -52,8 +52,10 @@ flowchart TB
 
 ## Try one handoff
 
-You’ll need **macOS or Linux, Node.js 24 or newer**, and supported coding clients on the same
-machine and operating-system user.
+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
+WSL, and live delivery reaches Claude Code, Codex and Antigravity CLI there too. See
+[Windows](docs/GETTING_STARTED.md#windows).
 
 ```bash
 npm install -g agents-can-communicate
@@ -96,11 +98,13 @@ 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 and Codex sessions on Apple Silicon
-macOS. 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.
+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.
 
 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

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

@@ -2,7 +2,6 @@
 // The relay the agent starts: `start` in its tool shell, `run` detached from it.
 // Fails open everywhere - `start` prints one line and exits 0; `run` answers its
 // ready line and exits quietly when anything it needs is missing.
-import { execFile } from "node:child_process";
 import { randomBytes } from "node:crypto";
 import { appendFile } from "node:fs/promises";
 import path from "node:path";
@@ -11,7 +10,7 @@ import { agentApiCommand, createAgentApi } from "@agents-can-communicate/adapter
 import { createRelay } from "@agents-can-communicate/adapter-antigravity/relay";
 import { listRegistrations, newRelayId, relayDir } from "@agents-can-communicate/adapter-antigravity/relay-endpoint";
 import { findConversation, spawnRelay, startRelay } from "@agents-can-communicate/adapter-antigravity/relay-start";
-import { loadSessionBinding } from "@agents-can-communicate/adapter-sdk";
+import { loadSessionBinding, readProcessArgs } from "@agents-can-communicate/adapter-sdk";
 import { platformDataHome } from "@agents-can-communicate/cli";
 import { createCoordinationService } from "@agents-can-communicate/core";
 import { resolveClientPid } from "@agents-can-communicate/hook-runner/client-pid";
@@ -27,8 +26,7 @@ const ids = { next: kind => createId(kind, randomBytes) };
 const alive = pid => { try { process.kill(pid, 0); return true; } catch { return false; } };
 const READY_MS = 10_000;
 
-const argvOf = pid => new Promise(resolve => execFile("ps", ["-o", "args=", "-p", String(pid)],
-  { timeout: 1_000 }, (_error, out) => resolve(String(out ?? "").trim().split(/\s+/).filter(Boolean))));
+const argvOf = async pid => await readProcessArgs(pid, { timeoutMs: 1_000 }) ?? [];
 
 // Through the launcher that ran `start`, never this module directly: an entry
 // module does not run itself, and under the managed runtime the launcher takes

package/bin/entrypoints/acc-hook.mjs

@@ -10,26 +10,36 @@ import { pathToFileURL } from "node:url";
 
 import { createId } from "@agents-can-communicate/protocol";
 import { runHook } from "@agents-can-communicate/hook-runner";
-import { hookEntrypointFor, resolvePinnedGeneration } from "@agents-can-communicate/cli";
+import { hookEntrypointFor, resolvePinnedGeneration }
+  from "@agents-can-communicate/cli/hook-support";
 
-import { createAntigravityAdapter } from "@agents-can-communicate/adapter-antigravity";
-import { createClaudeCodeAdapter } from "@agents-can-communicate/adapter-claude-code";
-import { createCodexAdapter } from "@agents-can-communicate/adapter-codex";
-import { createGeminiCliAdapter } from "@agents-can-communicate/adapter-gemini-cli";
-import { createGrokAdapter } from "@agents-can-communicate/adapter-grok";
-import { createKimiAdapter } from "@agents-can-communicate/adapter-kimi";
-
-const adapters = {
+// A hook runs one client's adapter, and loads only that one: every other
+// adapter was a set of modules loaded on each turn and never run, about a
+// millisecond each on windows-latest.
+const ADAPTERS = {
   // Registered like any other client. Its hook commands carry an extra
   // argument - the event name - because this client's payload has none.
-  antigravity: createAntigravityAdapter(),
-  claude_code: createClaudeCodeAdapter(),
-  codex: createCodexAdapter(),
-  gemini_cli: createGeminiCliAdapter(),
-  grok: createGrokAdapter(),
-  kimi: createKimiAdapter(),
+  antigravity: () => import("@agents-can-communicate/adapter-antigravity")
+    .then(module => module.createAntigravityAdapter()),
+  claude_code: () => import("@agents-can-communicate/adapter-claude-code")
+    .then(module => module.createClaudeCodeAdapter()),
+  codex: () => import("@agents-can-communicate/adapter-codex")
+    .then(module => module.createCodexAdapter()),
+  gemini_cli: () => import("@agents-can-communicate/adapter-gemini-cli")
+    .then(module => module.createGeminiCliAdapter()),
+  grok: () => import("@agents-can-communicate/adapter-grok")
+    .then(module => module.createGrokAdapter()),
+  kimi: () => import("@agents-can-communicate/adapter-kimi")
+    .then(module => module.createKimiAdapter()),
 };
 
+// The adapters this hook can use: its own, or none for an id nobody registered,
+// which runHook answers the way it always has.
+async function adaptersFor(adapterId) {
+  if (!Object.hasOwn(ADAPTERS, adapterId)) return {};
+  return { [adapterId]: await ADAPTERS[adapterId]() };
+}
+
 const readStdin = () => new Promise(resolve => {
   // A hook is always given its payload on stdin, but a client that closes it
   // without writing must not leave this process hanging in front of a turn.
@@ -50,7 +60,7 @@ import { completeHookOutput } from "./hook-output.mjs";
 // a hook that has no pin to look up pays nothing beyond it. Any adapter or
 // payload that will not yield a session id simply has no pin to find, same as
 // today's no-pin behaviour.
-async function harnessSessionIdFor(adapterId, payload, args) {
+async function harnessSessionIdFor(adapters, adapterId, payload, args) {
   try {
     const event = await adapters[adapterId]?.normalizeHook(payload, { args });
     return typeof event?.sessionId === "string" ? event.sessionId : null;
@@ -75,9 +85,10 @@ async function harnessSessionIdFor(adapterId, payload, args) {
 // mid-resolution by another hook for the same session, or simply wrong)
 // could say. Unbounded delegation would be a hang, worse than any of the
 // failures this file already falls open from.
-async function delegateToPin({ managerRoot, packageRoot, adapterId, payload, args, delegated }) {
+async function delegateToPin({ managerRoot, packageRoot, adapters, adapterId, payload, args,
+  delegated }) {
   if (delegated || managerRoot === null || packageRoot === null) return false;
-  const harnessSessionId = await harnessSessionIdFor(adapterId, payload, args);
+  const harnessSessionId = await harnessSessionIdFor(adapters, adapterId, payload, args);
   if (harnessSessionId === null) return false;
   const pinned = await resolvePinnedGeneration({ root: managerRoot, harnessSessionId, active: packageRoot });
   if (pinned === null) return false;
@@ -103,7 +114,10 @@ export async function main({ managerRoot = null, packageRoot = null, payload, de
     }
   }
 
-  if (await delegateToPin({ managerRoot, packageRoot, adapterId, payload, args, delegated })) return;
+  // A broken adapter module fails the hook open like any other error here.
+  const adapters = await adaptersFor(adapterId).catch(() => ({}));
+  if (await delegateToPin({ managerRoot, packageRoot, adapters, adapterId, payload, args,
+    delegated })) return;
 
   const result = await runHook({ adapterId, payload, args, adapters,
     runtime: { clock: { now: () => new Date().toISOString() },

package/bin/entrypoints/hook-output.mjs

@@ -56,16 +56,25 @@ function tryWrite(stream, output) {
   }
 }
 
+const RECOVERY = new Map([
+  ["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"
+    + " no Windows shell quotes alike; rename it and restart the client"],
+]);
+
+// The step a hook was in when its budget ran out, as the runner names it: a few
+// plain words, never text from the hook's input.
+const PHASE = /^[a-z][a-z ]{0,59}$/;
+
 export async function completeHookOutput(result,
   { stdout = process.stdout, stderr = process.stderr } = {}) {
   if (result.failed || result.timedOut) {
     // Only a known code selects static recovery advice. Arbitrary payload or
     // filesystem error text must never become client-visible instructions.
-    const recovery = result.failureCode === "workspace_contains_runtime"
-      ? ": workspace contains ACC runtime state; open a project directory and restart the client"
-        + " (or set ACC_DATA_HOME outside the workspace)"
-      : "";
-    tryWrite(stderr, `acc: coordination unavailable${recovery}; hook continued without context\n`);
+    const recovery = RECOVERY.get(result.failureCode) ?? "";
+    const held = result.timedOut && PHASE.test(result.phase ?? "") ? ` (timed out while ${result.phase})` : "";
+    tryWrite(stderr, `acc: coordination unavailable${recovery}${held}; hook continued without context\n`);
   }
   try {
     await writeOutput(stdout, result.stdout ?? "", { deadlineAt: result.deadlineAt });

package/docs/ADAPTER_AUTHORING.md

@@ -92,6 +92,30 @@ command that matches neither resolves nothing, and the failure is silent: the se
 `pid: null`, falls back to reading presence by age alone, and is not pinned to its
 generation, with nothing telling you why.
 
+Some vendors ship a second product that runs the same hooks: Antigravity 2.0, the desktop
+app, runs `~/.gemini/config/hooks.json` under its own language server, with no `agy`, on a
+version line of its own. Declare such a product as a variant and recognise its process:
+
+```js
+client: { command: "agy", certificationName: "antigravity-cli", versionArgs: ["--version"],
+  variants: [{ certificationName: "antigravity-desktop", displayName: "Antigravity" }] },
+identifyClientProcess: entry => /* null, or { certificationName, version } */,
+clientVersionOf: async ({ pid, entry, env }) => /* the running client's version, or null */,
+```
+
+- `identifyClientProcess(entry)` is called with each ancestor `{ comm, args }` before the
+  `client.command` match. It is synchronous and reads only the entry it is given; a throw is a
+  "no". A `certificationName` that names no declared variant is ignored, with its version.
+- Evidence may name a declared variant. A variant is judged only by its own evidence: its
+  versions count on its own line, so the primary client's captures never stand in for it.
+  Declaring a capability `true` still needs passing evidence of the primary client.
+- The session's version is, in order: the version `identifyClientProcess` returned, then
+  `clientVersionOf()`, then the client's own executable when `ps` names it by absolute path,
+  then `client.command` on `PATH`. The `PATH` probe alone named the wrong build for a
+  Claude.app session (its own claude, 2.1.286, against 2.1.289 on `PATH`) and for every
+  Claude Code session that outlived an in-place update; Claude Code's adapter therefore reads
+  the version from the session record Claude Code keeps for that pid.
+
 ## Declare only proven capabilities
 
 Fourteen booleans in four groups, declared in the manifest's `capabilities` object:
@@ -168,6 +192,11 @@ The rules `defineAdapter` enforces, and the ones the runtime applies:
   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.
+- An anchor may name a declared variant, `{ version, protocolContract, client }`, for a
+  delivery protocol only that product speaks. Each protocol's floor is its own first passing
+  capture: a handshake or probe is judged against the floor of the protocol it reports, and
+  one protocol cannot be anchored for two products. `minimum` stays the primary client's
+  first capture, and `knownBad` names the primary client's versions.
 - 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

package/docs/CAPABILITIES.md

@@ -4,8 +4,8 @@ Use this page to set expectations after installation. Integration means ACC can
 peer awareness and coordination instructions; it does not guarantee what a model will do
 with them. Delivery also varies independently from awareness. The durable inbox works for
 every participant, a client at or after a captured version may add next-turn delivery, and the
-experimental Codex LocalDaemon, Claude Code inbox wake and Antigravity CLI relay paths can
-deliver while a session is idle.
+experimental Codex LocalDaemon, Claude Code inbox wake and Antigravity relay and desktop paths
+can deliver while a session is idle.
 
 Capability honesty separates four questions that are easy to collapse:
 
@@ -64,16 +64,17 @@ What may refuse live delivery is exactly three things:
 
 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
+that transport. 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. 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, 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. |
+| 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; reply routing is 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; install allows that command too, so the agent starts the relay without a prompt (1.2.16, 2026-10-04); on Windows, where install adds no rule, the operator approves it 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 adds the prefix rule `command(<wrapper>)` to the client's settings, except on Windows, 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. On Windows the relay listens on a named pipe, `\\.\pipe\acc-relay-<32 hex>`, starts with `node`, and runs `agy.exe` itself, never a `.cmd`, since the message reaches agy as an argument. |
+| Antigravity 2.0 (desktop app) | 2.19.1 on darwin-arm64, captured 2026-10-04. The app runs the same `~/.gemini/config/hooks.json` under its own language server, with no `agy`, so ACC identifies the session by that server and the version on its command line (`--override_ide_version`), and judges it by the desktop's own evidence, never by Antigravity CLI's version line. `SessionStart` and `PreInvocation` fire; a peer message reaches the model at the next model invocation. Live push (2.19.1, darwin-arm64, experimental, recorded opt-in) needs no relay and no command from the agent: ACC reads the endpoint from the language server's command line when it binds and when it delivers, keeps the token only in one `agentapi` child's environment, and pushes into the conversation through the server's own `agentapi`. A product capture passed all six cases: an idle conversation woke with no user input; a push during a long answer was shown after it, uninterrupted; the woken agent answered with `acc reply` without an approval prompt; a resent message reached the model once; with the app quit the message stayed queued; after a restart the conversation's next turn bound it again. The app runs no `SessionStart` for a conversation it reopens, so after a restart live delivery returns at that next turn. One language server serves every window and conversation, so a desktop participant goes offline when the app quits. The app runs the agent's commands in a sandbox where ACC's wrapper cannot run; the model then retries outside it, which the app allows by the grants in `~/.gemini/config/config.json`, and install adds ACC's rule there once the app has run. Installing the integration still needs Antigravity CLI, whose `agy -p "/hooks"` reads the registration back. |
+| 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. On macOS and Linux, install adds ACC's own Codex rules file, so the commands a participant runs need no approval and Codex's auto-review never judges a message to a local peer. On Windows, where Node cannot open the daemon's AF_UNIX socket, ACC speaks the same protocol over the stdio of `codex app-server proxy` (measured on 0.159.3); Codex starts its daemon only from a terminal that is not elevated. Embedded or unreachable sessions keep their inbox. The Codex app (inside ChatGPT.app, read on 26.928) runs every chat on a private app server over stdio rather than the shared daemon (openai/codex#41014); its chats run ACC's hooks, receive messages at their next turn, and are reported as `client_session_embedded`. Native `replyRoute` remains false. |
+| 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, `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. Claude.app runs a local Code session on a Claude Code build of its own with the same `~/.claude`: such a session registers the same inbox (`entrypoint: claude-desktop`), and on 2.1.286 (2026-10-04) an idle one woke and answered with `acc reply` with no adapter change. Its Cloud, SSH and Cowork sessions run on another machine. ACC takes a session's version from the record Claude Code keeps for that process, because the `claude` on `PATH` can be another build. On native Windows the inbox is a named pipe, `\\.\pipe\LOCAL\cc-msg-<32 hex>`, that drops a frame without an auth line; ACC authenticates with the peer key Claude Code publishes beside the session record for other sessions of the same user, never the session's own token, so the recipient's inbound settings apply as on POSIX. Measured on 2.1.286; the real-clients CI job wakes an idle interactive Claude Code on Linux and on Windows. |
 | 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. |

package/docs/CLI.md

@@ -369,6 +369,11 @@ before leaving, request the concrete continuation and obtain a substantive reply
 | `acc help` | — |
 | `acc version` | — |
 
+`acc uninstall` takes back what the current ACC data home installed. A client on the machine
+that this data home has no install record for - one another data home wired, such as your own
+beside an isolated `ACC_DATA_HOME` - is skipped with the reason; name it with `--adapter` to
+remove its ACC wiring anyway.
+
 `--delivery off|actionable|all` is a per-client recipient policy request, not a capability
 switch, and the default is `off`. `--adapter` is repeatable to name several clients. An
 explicit `--delivery` applies uniformly and never prompts; omitting it on an interactive

package/docs/CONFIGURATION.md

@@ -218,26 +218,56 @@ 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.
 
+### Codex command approval
+
+Codex asks before a command that wants to leave its sandbox. With
+`approvals_reviewer = "auto_review"`, a model reviews that request instead of you, and it can
+refuse an ACC message that names a branch or a path as disclosure to an outside party. So
+`acc install` adds ACC's own rules file on macOS and Linux:
+
+```text
+~/.codex/rules/agents-can-communicate.rules
+  prefix_rule(pattern = ["<home>/.agents/acc-local/plugins/agents-can-communicate/acc-cli.sh",
+                         ["work", "claim", "release", "message", "request", "inbox", "reply",
+                          "ack", "status", "sync", "finish"]],
+              decision = "allow")
+```
+
+Codex loads every `*.rules` file in that directory. A command the rule allows needs no
+approval, so no reviewer sees it. Only ACC's wrapper and only the commands a participant runs
+are allowed: `acc install`, `uninstall`, `update` and `config` still ask. Install does not ask
+about the rule; it is part of ACC's Codex integration, as its hooks are. A file of that name
+that ACC did not write stays yours, and ACC adds no rule then. So does ACC's file once you edit
+it, for example to take a command out: reinstall and update leave it as it is, and doctor
+reports it as edited. A wrapper path that a rule cannot
+hold as it is gets none either. `acc uninstall` removes the file while it is unchanged, and
+`acc doctor` asks for `acc install --adapter codex` when it is missing. Windows gets no rule:
+how Codex matches a PowerShell command against one is unmeasured.
+
 ### 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:
+and the peer would get no answer until someone approved it. The relay that lets ACC wake an
+idle session is started by the agent too, with a command the client would also ask about. So
+when `acc install` installs the Antigravity adapter, it always adds two rules to the client's
+own settings:
 
 ```text
 ~/.gemini/antigravity-cli/settings.json
   permissions.allow: command(<home>/.gemini/config/acc/acc-cli.sh)
+                     command(sh "<home>/.gemini/config/acc/acc-relay.sh" start)
 ```
 
 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.
+prompts. The second rule is the exact command that starts live delivery, in the words the
+client itself saves when you choose to always allow it. Every other command still asks.
+Install does not ask about the rules, and the delivery policy does not change them: they are
+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
+records what it added in its own data home. `acc uninstall` removes every copy of each 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
@@ -246,9 +276,10 @@ 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.
+shell metacharacter, the path needs quotes, no rule can match it, and ACC adds neither rule:
+without the wrapper's, the agent would still ask before each ACC command.
+`acc doctor` reports each rule as present, absent, or unable to apply, and asks for
+`acc install --adapter antigravity` when one of ACC's rules is missing.
 
 ## Override local paths and identity
 
@@ -258,7 +289,7 @@ that resolves inside a workspace.
 
 | Variable | Purpose |
 |---|---|
-| `ACC_DATA_HOME` | Base directory under which ACC creates `acc/` for runtime and coordination state. Defaults: `~/Library/Application Support` on macOS; `~/.local/share` on Linux, or `XDG_DATA_HOME` |
+| `ACC_DATA_HOME` | Base directory under which ACC creates `acc/` for runtime and coordination state. Defaults: `~/Library/Application Support` on macOS; `~/.local/share` on Linux, or `XDG_DATA_HOME`; `%LOCALAPPDATA%` on Windows |
 | `ACC_CONFIG_HOME` | Parsed and validated path override; no current configuration-storage consumer |
 | `ACC_CACHE_HOME` | Parsed and validated path override; no current cache-storage consumer |
 | `ACC_PARTICIPANT` | Which participant a session belongs to, when the client does not say |

package/docs/DESIGN_DECISIONS.md

@@ -90,8 +90,6 @@ where a guard stops behaves better than one that believes it absolute.
 4. **Multi-root discovery rules** beyond the current `roots` list.
 5. **Default claim lease length** for hook-only adapters. A hook-only session cannot sustain
    a short renewal cadence, so lease policy must not assume one.
-6. **Windows.** Measured as not working, not merely untested — see the
-   [repository changelog](https://github.com/automatis-tools/agents-can-communicate/blob/main/CHANGELOG.md).
 
 ---
 

package/docs/GETTING_STARTED.md

@@ -13,7 +13,8 @@ pair or session-bound ACC MCP tools. See [CLI ownership](CLI.md#coordinate-from-
 
 ## 1. Install once on this machine
 
-ACC requires macOS or Linux and Node.js 24 or newer.
+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.
@@ -72,8 +73,9 @@ Code opens for every session. After you opt in, start Claude Code with your ordi
 ACC adds no launch flag, shell change or wrapper. A session in `bypassPermissions` mode asks
 you to approve each ACC wake. See
 [held or dropped wakes](TROUBLESHOOTING.md#a-claude-code-session-holds-or-drops-acc-wakes).
-The feature is off by default, can spend model tokens, and currently requires Apple Silicon
-macOS and Claude Code 2.1.282 or newer. You do not need it for durable messages or supported
+The feature is off by default, can spend model tokens, and requires Claude Code 2.1.282 or
+newer. Local sessions in Claude.app's Code tab wake the same way; its Cloud, SSH and Cowork
+sessions run on another machine. You do not need it for durable messages or supported
 next-turn delivery.
 
 ## 2. Open two sessions and give them ordinary tasks
@@ -142,8 +144,8 @@ Antigravity CLI carries one extra condition: its hooks are given a project direc
 when the session has an open workspace. A session started without one attaches nothing, and
 the client shows no hook output to say so - `acc doctor` names it.
 
-Codex LocalDaemon and the Claude Code inbox wake offer optional native delivery on
-Apple Silicon macOS. They are experimental and can spend tokens. Codex queues a message
+Codex LocalDaemon and the Claude Code inbox wake offer optional native delivery. They are
+experimental and can spend tokens. Codex queues a message
 until a running turn finishes. A busy Claude Code session takes the wake between two tool
 calls. Claude Code requires 2.1.282 or newer and recorded opt-in, and it wakes through the
 inbox that each session opens itself. Codex requires 0.152.1 or newer, LocalDaemon
@@ -157,7 +159,12 @@ three times while none is running, and you approve that command at the client's
 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.
+Antigravity 2.0, the desktop app, runs the same hooks under its own language server, and ACC
+delivers into its conversations through that server: nothing for the agent to start. The app
+keeps its own command grants in `~/.gemini/config/config.json`; install adds ACC's rule there
+once the app has run. After the app restarts, a conversation is reachable again from its next
+turn. Chats in the Codex app run on the app's own server and get messages at their
+next turn. [Capabilities](CAPABILITIES.md) explains policy, versions and fallback.
 
 Delivery evidence is deliberately narrow: `queued -> offered -> retrieved -> acknowledged`.
 An offer is not proof that the model read anything, retrieval is not proof of attention, and
@@ -199,5 +206,31 @@ acc uninstall
 Uninstall removes only bytes ACC wrote that still match its install record. User edits are
 reported and preserved.
 
+## Windows
+
+ACC runs natively on Windows 10 and 11, with no WSL. Install it the same way, in PowerShell or
+in a Command Prompt:
+
+```powershell
+npm install -g agents-can-communicate
+acc install
+```
+
+What is different on Windows:
+
+- ACC keeps its state in `%LOCALAPPDATA%\acc`, never in the roaming profile.
+- Each client's hooks run a small Node script instead of a shell script, in the form that
+  client's hook runner reads. `node` must be on `PATH` for Grok and Antigravity CLI hooks.
+  Claude Code needs 2.1.139 or later.
+- Live delivery reaches a running session as on macOS and Linux: Claude Code through its inbox
+  pipe, Codex through its app-server daemon, Antigravity CLI through ACC's relay. Codex starts
+  its daemon only from a terminal that is not running as administrator.
+- Antigravity CLI cannot run a hook whose path is quoted. When your profile path has a space,
+  ACC writes the path's 8.3 short name. ACC adds no allow rule on Windows, so Antigravity CLI
+  asks before each ACC command.
+- The first hook after the machine starts can take a few seconds, because ACC reads the
+  process tree through WMI, in Windows Script Host or, where Script Host is off, PowerShell.
+  If it runs out of time, the session attaches on the first prompt instead.
+
 Next: [Why ACC](WHY_ACC.md) · [Capabilities](CAPABILITIES.md) · [CLI](CLI.md) ·
 [Troubleshooting](TROUBLESHOOTING.md)

package/docs/HOW_IT_WORKS.md

@@ -102,16 +102,16 @@ All recipients have the same durable record, but adapters expose different accel
 - **Next normal turn:** exact captured versions of Codex, Claude Code, Gemini CLI, Antigravity CLI and Kimi
   Code can receive complete attributed peer context when the user next prompts that client.
   This does not wake an idle session.
-- **Optional Claude Code inbox wake:** on Apple Silicon macOS with Claude Code 2.1.282 or
-  later, ACC wakes the session through the inbox socket that the session opens itself. The
-  wake is one line of fixed ACC text with the message id. It carries no subject, body or
+- **Optional Claude Code inbox wake:** with Claude Code 2.1.282 or later, ACC wakes the
+  session through the inbox that the session opens itself: a Unix socket on macOS and Linux,
+  a named pipe on Windows. The wake is one line of fixed ACC text with the message id. It carries no subject, body or
   sender name. An idle session starts a turn. A busy session takes the wake between two tool
   calls and keeps its turn. Each delivered wake fires `UserPromptSubmit`, ACC's next-turn
   hook, which shows the message in its untrusted block. The model answers with
   `acc reply`. This is experimental, off by default and can spend tokens. Claude Code's
   own inbound controls apply to each wake.
 
-- **Optional Codex LocalDaemon delivery:** on Apple Silicon macOS, a captured
+- **Optional Codex LocalDaemon delivery:** a captured
   minimum of 0.152.1 plus a current probe and exact session checks allow delivery
   to an independently opened thread. It is experimental, off by default, and can
   spend tokens. Messages wait for a running turn to finish; a daemon-retained
@@ -120,13 +120,18 @@ All recipients have the same durable record, but adapters expose different accel
   and does not manage the vendor daemon during message delivery. Separately,
   [confirmed update maintenance](UPGRADING.md#confirmed-client-service-maintenance) can restart it.
 
-- **Optional Antigravity CLI relay:** on Apple Silicon macOS with 1.2.7 or later, the session
-  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
+- **Optional Antigravity CLI relay:** with 1.2.7 or later, the session endpoint exists only
+  in the agent's own shell, so ACC's context asks the agent once per conversation to start a
+  relay, a command install allows. 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. The
   woken agent's ACC commands run without the client's approval prompt because install adds
-  one allow rule for ACC's wrapper.
+  an allow rule for ACC's wrapper. On Windows install adds no rule, so the client asks first.
+
+- **Optional Antigravity desktop delivery:** with Antigravity 2.19.1 or later, ACC pushes a
+  message into a desktop conversation through the app's own language server, reading its
+  endpoint when it binds and when it delivers, and storing no token. The agent starts
+  nothing. It is experimental, off by default, and can spend tokens.
 
 Grok, generic MCP, unsupported versions and uncaptured platforms use inbox polling.
 [Capabilities](CAPABILITIES.md) lists evidence and fallback.

package/docs/SECURITY_MODEL.md

@@ -103,12 +103,32 @@ 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.
+On macOS and Linux, installing the Codex adapter also writes ACC's own Codex rules file. It
+allows ACC's wrapper to run the commands a participant runs, such as `message` and `reply`,
+without an approval, so Codex's auto-review never judges a message to a local peer. Install,
+uninstall, update and config still ask. See
+[Codex command approval](CONFIGURATION.md#codex-command-approval).
+
+Antigravity CLI asks before each shell command. Installing its adapter adds two rules to that
+client's `permissions.allow`: a prefix rule for ACC's own wrapper path, and the exact command
+that starts the relay. The agent then runs every ACC command, and starts live delivery,
+without a prompt, including when a peer's message prompts it. Every other command still asks.
+ACC records the rules it added and uninstall removes only those.
 It never writes a settings file that it cannot parse. See
 [Antigravity CLI command approval](CONFIGURATION.md#antigravity-cli-command-approval).
+Antigravity 2.0, the desktop app, keeps its grants in `~/.gemini/config/config.json`. Once the
+app has created that file, install adds the same wrapper rule there, under the same ownership
+record, and never creates the file itself.
+
+Antigravity 2.0 starts its language server with the server's CSRF token on its command line,
+where every process on the machine can read it. To deliver into a desktop conversation, ACC
+reads that command line from the one server its own hook ran under: the pid and start time
+recorded when the session bound, and the arguments checked again at every use. The token goes
+into the environment of one `agentapi` child for one call and nowhere else: not into the
+endpoint record, the delivery binding, the native-attempt record, logs or diagnostics. The
+record names the server's pid, its start time and the loopback port that answered `/healthz`.
+What the token lets ACC do there is what the relay does for Antigravity CLI: put one fenced,
+ACC-rendered peer message into one conversation.
 
 ## Claims
 
@@ -125,7 +145,14 @@ from operating merely because its own state is unavailable.
 ## Filesystem and installation
 
 - Runtime state, bindings, sockets, and install ownership records stay outside repositories.
-- Managed paths are checked for containment and symlink escape.
+- Managed paths are checked for containment and symlink escape. Windows has no `O_NOFOLLOW`:
+  ACC refuses a symlink or junction at the last component by name, then checks that the
+  opened handle is the file it checked.
+- On Windows, ACC state lives in `%LOCALAPPDATA%`, whose ACL grants only the user, SYSTEM and
+  Administrators; files inherit it. Mode bits do not exist there.
+- A workspace config root that starts with a separator or a drive letter is refused on every
+  platform. On Windows such a root could name another drive or a network share (`\\host\share`),
+  which a hook would then contact.
 - Store publication uses atomic no-replace behavior, journaling, and writer locks.
 - Corrupt or incompatible store versions fail closed before mutation.
 - Client installers preserve unrelated settings and record content hashes.