43 Commits

Author	SHA1	Message	Date
Ben Brandt	de96cef382	feat: add ultracode session config option (#1438) ... Adds an **Ultracode** session config option. It turns on Claude Code's dynamic workflows for every task, at any effort level. Clients that support boolean config options get a native switch; the rest get an On/Off select. This follows the Fast mode pattern. ## How the CLI handles ultracode (2.1.310, checked against the bundled binary and a live session) - **Which models:** ultracode works on exactly the models that support `xhigh` effort. The CLI uses the same check for both. So Opus 4.7+, Sonnet 5+, Haiku 5.5 and Fable qualify; Opus 4.6 and Haiku 4.5 don't. Effort level no longer matters. - **Workflows:** dynamic workflows must be enabled. They are off by default on Pro plans, and org or managed policy can turn them off. - **State reporting:** `query.getSettings()` returns `applied.ultracodeAvailable` and `applied.ultracodeRequested`. The CLI's schema says hosts should "offer an Ultracode control only while this is true". This method exists at runtime but is missing from the SDK's `.d.ts`, so the adapter reads it with a cast and falls back to settings and model data when it is absent. - **Unsupported requests:** `applyFlagSettings({ultracode})` is never validated. The request is stored and stays in place across model switches; it takes effect whenever the model supports it. - **Effort changes:** an `effortLevel` change sent without an `ultracode` key turns ultracode off. ## Behavior - **Visibility:** at session start, one `getSettings()` call decides availability and the starting value. Model switches combine the workflows result learned at start with the new model's `supportedEffortLevels`, so the switch path makes no extra control request. - **Value:** the session tracks the user's choice, like `fastModeEnabled`. The option hides on unsupported models and comes back with the same value. - **Effort applies:** `effortFlagSettings` now carries the session's toggle instead of `settings.ultracode`. This applies at the initial apply, on model switch, and from the effort picker, so effort changes no longer turn ultracode off. - **Clear context:** the clear-context restart restores the toggle, as it does Fast mode. ## Known limitation If a user types `/effort ultracode on` as a prompt, the toggle does not update. The adapter already doesn't pick up effort changes typed as `/effort` commands. ## Testing - New `src/tests/ultracode-config.test.ts`. It covers the helpers and session behavior: seeding from the CLI's report, hiding while workflows are off, following the model's support, keeping the value across effort and model switches, and rejected applies. - New clear-context restore test. `effortFlagSettings` tests updated. - Live probe against CLI 2.1.310 confirmed the `getSettings` fields, the `xhigh` proxy (`claude-opus-4-6` reports unavailable while the request stays in place), and the effort/key behavior. - `npm run check`, `npm run build`, `npm run test:run` all pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-26 12:34:13 +00:00
Ben Brandt	59e292e29f	feat: report RFD delegations as linked session messages (#1405) ... ## Summary For a client on the subagents RFD (every ACP v2 client, and v1 clients that declare `subagents`), session messages now replace the Agent/Task call that launches a child. The parent no longer sees that tool call. AIR's form is unchanged. - **Prompt.** The launch's prompt is a `session_message` in both transcripts: the parent's outgoing view and the child's incoming one. Both use the launch's tool use id, and each names the other with `recipientMessageId` / `senderMessageId` from agentclientprotocol/agent-client-protocol#2465. - **Answer.** A foreground child's answer, from the launch's result, is the child's `session_message` to the parent (`<launch id>:reply`). It uses the result as `AgentReporter` renders it, so the model-facing `agentId: …` line and `<usage>` block are gone. A failure or cancellation comes from the child's `idle` stop reason, which it already reported. A background launch's result gets no reply. - **Hand-back mode.** Claude Code (seen with 2.1.303) can have the child hand its report back with a `SubagentHandback` call; the Agent result then only says that the report "was delivered to you as a message". That call is reported as the child's message to the parent, in both transcripts and linked the same way, and the launch's reply is skipped for that run. A failed hand-back delivered nothing, so it stays a tool call of the child. - **Unexposed work.** A launch whose child is never exposed is shown as a tool call after all, with its final status (`unexposedControlFallback`, the former `failedControlFallback`). - **Hidden launches by id.** The adapter's own report that closes an unfinished call (for example at a forced cancel) carries no `toolName`, so the runtime tracks hidden launches by id to keep that report from reaching the client for a call it never saw. - **Replay** sends the same messages from the child's transcript: the launch's prompt, the reply, and hand-backs. A launch without Claude Code's metadata file keeps its tool call and the missing-history notice. Replay can't tell a child's runs apart, so any hand-back in its transcript suppresses its launch's reply. - **SendMessage** calls stay tool calls of their sender, and the child gets the incoming view without references, as before. - README's subagent section describes the new behavior. Do not merge before agentclientprotocol/agent-client-protocol#2465 settles the field names: a merge to `main` publishes a preview right away. Clients on the published schema ignore the two fields (no `deny_unknown_fields` in the Rust schema; the scenario validation with the SDK's zod schema passes). ## Testing - `npm run build`, `npm run check` and `npm run test:run` pass (57 files, 4 skipped as before). - The six v2 `subagent-*.jsonl` scenario snapshots changed: the launch's tool-call updates are gone, the parent gets the outgoing view, the child's view carries `senderMessageId`, and foreground results became `:reply` messages. AIR snapshots are unchanged. - New unit tests cover hidden launches, nested launches, replies, failed and background launches, unexposed launches with both final statuses, the close report without a tool name, and hand-back success and failure, live and on replay. - A real run: the built adapter driven over v2 stdio with Claude Code, one foreground subagent asked to answer PONG, then `session/resume` with replay in a fresh process. Live and replay both showed the linked prompt (parent → child), the linked hand-back "PONG" (child → parent), and no Agent tool call.	2026-10-23 13:12:33 +02:00
Ben Brandt	4d378f93f3	feat: serve experimental ACP v2 (#1400) ... ## Summary The draft ACP v2 is no longer opt-in. The adapter always connects through the SDK's protocol router (as codex-acp does), so a client that asks for protocol version 2 or later in `initialize` gets v2, and every other client gets v1 as before. v2 is still experimental and follows the draft as it changes. - Removes `CLAUDE_AGENT_ACP_EXPERIMENTAL_V2`, which only turned on what is now the default. - Adds `CLAUDE_AGENT_ACP_PROTOCOL` to limit the adapter to one version: - unset, empty, or `auto`: both, picked by the client's `initialize`. - `v1`: a client that asks for v2 is negotiated down to v1. This is the escape hatch if a client's v2 handling breaks. - `v2`: a v1 client's `initialize` is rejected with `-32022 Unsupported protocol version`. - Any other value fails at startup, so a typo like `CLAUDE_AGENT_ACP_PROTOCOL=1` doesn't silently serve both. - Fixes the comment in `src/acp-subagents.ts` that said v2 clients don't get subagents. Note: a client that already sends `protocolVersion >= 2` switches to the v2 surface as soon as this lands on `main`, which publishes a preview. ## Testing - New routing tests: down-negotiation to v1, rejecting v1 when limited to v2, env parsing. - `npm run check`, `npm run build`, `npm run test:run` pass. - Ran the built binary over stdio with each setting: default → v2 for a v2 client, `v1` → protocol version 1, `v2` → `-32022` for a v1 client, invalid value → exits with an error at startup. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 13:37:06 +02:00
Ben Brandt	ba3c7be05e	feat: keep background subagents running after a parent cancel, for clients that can cancel them (#1348) ... Stacked on #1347, which gives each running child the `cancel` capability. Merge #1347 first; this PR's base is its branch. ## What changes On a client that gets the subagents RFD form (v1 with `clientCapabilities.subagents` and not AIR, and v2), `session/cancel` on the parent now spares background subagents. They keep running, as acp#2308 prescribes ("a background child that the cancelled work did not wait on may continue"), and the client can stop each one with its child's `cancel` from #1347. Foreground subagents that the turn waits on still stop. Plain v1 clients and AIR are unchanged: the interrupt still stops their background subagents, since they have no way to stop one. ## How - **The declaration.** Claude Code's interrupt kills background subagents and workflows unless the query declares `perTaskStopAffordance`. The SDK describes it as "this consumer renders a per-task stop control", and an RFD client now has that control. The adapter declares the option for those clients. It comes before `_meta.claudeCode.options`, so a client can turn it off. - **Workflows.** The declaration also spares background workflows (`local_workflow`). A workflow's agents are not subagent tasks and get no child session, so a client can't stop a workflow unless it is AIR with `asyncTasks`. When a session declares the option and the client has no such control, `session/cancel` stops each live background workflow with `Query.stopTask` after the interrupt. Workflows therefore behave as they did before. - **Background commands** survive an interrupt with or without the declaration (checked live and in the CLI code), so nothing changes for them. Where I read Claude Code 2.1.296's CLI: without the declaration, the interrupt runs a kill of every running background `local_agent` and `local_workflow` task. With it, the interrupt kills only observer tasks. Adapter interrupts name no prompt, so this runs on every `session/cancel`, including one with no turn running. The declaration's only other effect is on requests with `interrupt_if_running`, which the adapter never sends. ## Checks **Live, Claude Code 2.1.296, through the built adapter.** Every update was checked against the schema, and no run had a violation or left a tool call open. Survival was checked by whether the background command's process was alive 2 s after the cancel. | Client | Background work at the cancel | Result | |---|---|---| | v1 RFD | subagent running a command | Prompt `cancelled` 9 ms after the cancel. The child kept running, completed its command and reported `idle end_turn`. Claude Code's follow-up cycle then streamed to the root. | | v1 RFD | subagent with an open permission request | The request stayed open through the cancel. The client allowed it 5 s later, and the child ran the command and ended `idle end_turn`. | | v1 RFD | workflow | The workflow and its command stopped, with no follow-up cycle. Same as the plain client. | | v1 plain | subagent | Unchanged: the interrupt killed the child, and its command's tool call ended `failed`. | | v1 plain | workflow | Unchanged: stopped, no follow-up. | | v2 | subagent | Root `idle cancelled` 11 ms after the cancel. The child kept running and later reported `idle end_turn`, and the root went `running`, then `idle end_turn`, for the follow-up. | | v2 | workflow | Stopped, no follow-up. | **Direct SDK probes** decided the design: - With the declaration, an interrupt spares a background workflow. - Without it, the interrupt kills the workflow. - A `stopTask` on a workflow, before or after the interrupt, stops it and its command, and Claude Code starts no follow-up cycle, the same as when the interrupt killed it. **Tests:** - Option tests: the declaration for each client form, a caller's override, and when a cancel stops workflows. - Cancel tests: only workflows are stopped, after the interrupt and only when the flag is set. - Removing any of the eight rules fails a test. - `npm run check`, build and all 3020 tests pass, with no golden changes. ## Not covered - A paused background workflow (one Claude Code restored on a resume) would also be stopped at a cancel, where the interrupt left it alone. I didn't check whether such a workflow reports `task_started`. - Standard ACP has no control to stop background work that is not a session, such as a workflow or a background command. Only AIR has one, through its async tasks extension.	2026-10-14 21:56:01 +02:00
Ben Brandt	aeb69e7ed1	feat: let a client cancel one subagent with session/cancel on its child session (#1347) ... A client on the subagents RFD can now stop one subagent without cancelling the turn. Each running child is announced with `capabilities: { cancel: {} }`, and `session/cancel` with the child's session id stops that child's current work. ## What Claude Code does From direct SDK probes of `Query.stopTask(taskId)` and runs through the adapter (Claude Code 2.1.293 and 2.1.296): | Case | What Claude Code sends | |---|---| | Foreground subagent running a command | At once: `task_updated` `killed` and `task_notification` `stopped` for the subagent, `stopped` for its command's task, the command's interrupted result, then the Agent call's interrupted result (`non_execution_kind: "interrupted"`). The parent's turn goes on and ends normally. | | Background subagent | The same events and result, then Claude Code's follow-up cycle about the stop. | | Subagent with an open permission request | The request is withdrawn (its `AbortSignal` fires), and both calls get results. | | Subagent waiting on its own foreground subagent | The grandchild is stopped too, with its own `killed` and `stopped`, which is the cascade the RFD requires. | ## The change - **The grant:** `announceNativeSubagent` grants `cancel` to each live RFD child. A replayed child gets no capabilities, since it no longer runs (the RFD's freshness rule for reconnection). A routing-only ancestor that a restore announces gets none either. - **The cancel:** `cancel` checks first whether the session id is a child of one of its sessions (`NativeSubagentRuntime.cancelChild`), and if so calls `Query.stopTask` with the child's agent id. It sends no interrupt, so the parent's work goes on. A stop that Claude Code refuses is logged. - **The report comes from the SDK's events,** `killed` or `stopped`, which `finishTask` already turns into `idle` with `cancelled`. Accepting the stop is no evidence, as the RFD says, and a cancel that races with a child's end does not rewrite its outcome. - **Requests:** a request that the stop withdraws reports no `running` before `idle cancelled`. `awaitingUser` now counts cancels of the child and of its ancestors, as it counted the root's (#1337). An ancestor's cancel stops the foreground subagents under it. - **Unchanged:** AIR keeps its draft and grants nothing, and a cancel of a root session works as before. ## Evidence **Live, through the adapter** (Claude Code 2.1.296, Sonnet), every update checked against the schema, with no violations: | Run | Child | Parent | |---|---|---| | v1 RFD, foreground child running a command | `running`, `requires_action`, `running`, `idle cancelled` 9 ms after the cancel; its command `failed` | Agent call `failed`; turn ends `end_turn` | | v1 RFD, background child while v1 holds the turn | `idle cancelled`; its command `failed` | the held turn settles with `end_turn` | | v1 RFD, child with its permission request open | `requires_action`, then `idle cancelled`, with no `running` between | turn ends `end_turn` | | v2, foreground child | `idle cancelled` on the root's stream and its own | Agent call `cancelled`; root `idle end_turn` | No tool call was left open in any run. **Tests:** - `native-subagents.test.ts`: - `cancelChild` stops the child's task and reports nothing itself, and the SDK's `killed` reports `idle cancelled`; - no stop for a session that is no child, or for AIR; - no `running` for a request that the child's own cancel withdraws, or that its parent's cancel withdraws. - `acp-agent.test.ts`: `session/cancel` on a child calls `stopTask`, not `interrupt`, and the turn ends `end_turn`; a refused stop is logged; nothing happens for an unknown session id or an AIR child. - `acp-v2.test.ts`: the same over v2, with the child's `idle cancelled` on both streams. - **Golden files:** the six v2 subagent golden files gain `capabilities: { cancel: {} }` on each announcement, and nothing else. No AIR golden file changes. - **Mutation checks:** removing each of these fails at least one test: - the grant; - the routing to the child; - the child's cancel count; - the ancestors in the count; - the AIR exclusion; - the error handling. So does reporting `idle cancelled` as soon as the stop is accepted. `npm run check`, build and the full suite (3014 tests) pass. ## Not changed, and a decision - **A parent cancel still stops background subagents.** Claude Code does that because the adapter does not declare the SDK's `perTaskStopAffordance` option. Declared, an interrupt spares background agents and background shell commands (checked live: both ran to completion after the interrupt), as agentclientprotocol/agent-client-protocol#2308 prefers. Background shell commands would then outlive a cancel too, and ACP has no control to stop them, so declaring it is left for a separate decision. - **Order:** Claude Code sends the stopped child's command result right after its `killed` event, so the client sees `idle cancelled` a few milliseconds before that call ends. The RFD has the client mark the child's unfinished calls cancelled at that point and still accept later updates. - **On v2,** the stopped child's command ends `failed`, not `cancelled`: Claude Code's result for a subagent's command carries no non-execution kind.	2026-10-14 21:56:01 +02:00
Ben Brandt	c7425e4e04	fix: report no running for a subagent's request that a cancel withdraws, for subagents RFD clients (#1337) ... ## Problem For a subagents RFD client, a subagent's child session reports `requires_action` while one of its permission or question requests is open, and `running` again once its last open request ends (#1322, `NativeSubagentRuntime.awaitingUser`). A request that ends because the work was **stopped** is not an answer, but it still reported `running`. On `main`, with Claude Code 2.1.296, a foreground child whose Bash permission request is open, and a cancel on the parent: | What stops the work | States the child reported | | --- | --- | | `session/cancel` (v1, and v2 on the child's own stream) | `running`, `requires_action`, **`running`**, `idle cancelled` | | `session/close` | `running`, `requires_action`, **`running`**, and then nothing: a closed session reports no `idle` | Claude Code's interrupt withdraws the request, so the SDK aborts the signal of the `canUseTool` call, the adapter sends `$/cancel_request`, and the request's `finally` reports `running`. The SDK's own report of the child's end (`task_updated killed`) comes a few ms later (3 to 4 ms in these runs), so the client shows a child that is being stopped as working. After a `session/close` nothing corrects it. ## Cause `awaitingUser` reported `running` whenever the last open request ended, whatever ended it. A request ends in two ways, the user answers it or Claude Code withdraws it, and a withdrawal alone does not say whether the work was stopped. Claude Code also withdraws a request when something else answers it, and then the child runs on. I ran one such case, a `PermissionRequest` hook that allows the command after 3 s: the child worked for 9 more seconds after the withdrawal, and `running` was right. (The CLI also re-checks a pending ask when its permission context changes, and withdraws it if that now allows the call. I did not manage to trigger that: `session/set_mode` to `bypassPermissions` left the request open in my run.) So "a withdrawn request reports no `running`" is wrong: that child would sit on `requires_action` for the rest of its run. Waiting for the child's next update instead does not help either: in that run the child's first update after the withdrawal came 8 s later, with the tool's result. ## Change A request reports no `running` when it was **withdrawn after a cancel that came while it was open**. Then Claude Code's interrupt withdrew it as it stopped the child, and the SDK's events report the child `idle`. - `NativeSubagentRuntime.parentCancelled` (called for `session/cancel`, and by the teardown of `session/close`) counts the cancels in the RFD form. It still reports nothing, so #2308 is unchanged: a child that keeps running keeps its requests and its state. - `awaitingUser` takes the request's `signal`, which the agent passes for permission requests and AskUserQuestion (`withChildAwaitingUser`). A request records the count when it opens. If its signal aborted and the count changed, its end reports no `running`. - Everything else is as before: a request that the user answers, also after the cancel, reports `running`; a withdrawal without a cancel reports `running`; two overlapping requests report once, when the last one ends, by how that one ended. - README: one clause in the work-state bullet of "Subagent sessions". AIR is unchanged: `awaitingUser` only runs in the RFD form, and the AIR golden files do not change. ## Evidence Live runs against Claude Code 2.1.296 (Sonnet), driving `dist/index.js` over stdio with a client that holds the child's permission request, validating every update and request against the SDK's JSON schema (0 violations in all runs): | Run | `main` | This PR | | --- | --- | --- | | v1, `session/cancel` | `running`, `requires_action`, `running`, `idle cancelled` | `running`, `requires_action`, `idle cancelled` | | v2, `session/cancel` (child's stream) | `running`, `requires_action`, `running`, `idle cancelled` | `running`, `requires_action`, `idle cancelled` | | v1, `session/close` | `running`, `requires_action`, `running` | `running`, `requires_action` | | v1, hook allows after 3 s, no cancel | `running`, `requires_action`, `running`, `idle end_turn` | the same | Tests (all fail without the rule, as checked by removing it): - `native-subagents.test.ts`: the cancel withdrawal (and the child's `idle cancelled` after it); a withdrawal without a cancel (the hook case, which a simpler "abort means stopped" rule fails); a request that outlives a cancel and is answered later; a cancel that came before the request opened; two overlapping requests, in each order. - `acp-agent.test.ts`: through `canUseTool`, with `agent.cancel` and `agent.closeSession` aborting the request as Claude Code does, and the hook case. - `acp-v2.test.ts`: the child's own `state_update` stream and the parent's copy. Removal checks, each run against the three test files: no rule (6 tests fail), the cancel not counted (6), the agent not passing the signal (3: agent cancel and close, v2), and the simple "any withdrawal" rule (3: the hook cases). `npm run check`, `npm run build` and `npm run test:run` pass (2935 tests; the scenario golden files do not change). ## Not covered - **A stream end without a cancel.** If Claude Code exits by itself, the SDK's cleanup aborts every request before the consumer reads the end of the stream, and nothing at that moment tells it from a hook's withdrawal. Live (`kill -9` of the CLI): `running`, then `idle`, 1 ms apart. The session is dead right after. A rule for it would be a timing one: report `running` for a withdrawal with no cancel one event-loop turn later, so that `finishAll` goes first. I tried it (`await new Promise((resolve) => setImmediate(resolve))` before the check in `awaitingUser`'s `finally`): the `kill -9` run then reports `running`, `requires_action`, `idle`, and the hook run still reports `running` 1 ms after the withdrawal. I did not include it. It only works when the end of the stream reaches `finishAll` in the same turn (a worker shutdown publishes its failure notice first, for one), and it hides an ordering assumption about the consumer. Your call. - **Claude Code stopping a child on its own** (the model's TaskStop) while its request is open: the same shape, no cancel. - **The root session on v2** has the same flicker for its own request: `requires_action`, `running`, `idle cancelled` (live, v2). It comes from `syncAwaitingUser`, not from this runtime, and is not changed here. - A background child that outlives a cancel and whose still-open request a hook then withdraws would report no `running`. Claude Code stops background children at an interrupt today, so it does not arise. Related, and independent: a child's AskUserQuestion is not abandoned on an abort when its client ignores `$/cancel_request` (#1338). The two PRs touch the same call site and merge cleanly in either order (checked with `git merge-tree`).	2026-10-14 11:47:28 +02:00
Ben Brandt	9a1b90fb9d	fix: close the tool calls of a background subagent that the SDK reports stopped after a cancel (#1336) ... ## Problem After `session/cancel`, the tool call of a **background** subagent's command stays `pending` for good when no turn is left to settle. Example, live (Claude Code 2.1.296, Sonnet): a background subagent runs `python3 -c "import time; time.sleep(60)"`, and the client cancels while it runs. Either the session is idle, or v1 holds the prompt open for the subagent and the cancel settles it at once. Claude Code's interrupt stops the subagent: the SDK reports `task_updated` `killed` and `task_notification` `stopped`, and the RFD form reports the child `idle` `cancelled`. The command's call is never closed, in the root session or in the child's. ## Cause #1327 closes a cancelled turn's open tool calls when the turn settles (`closeCancelledToolCalls`), and leaves a background subagent's calls open, because the interrupt may not stop it. Here the turn is already settled (the cancel settled the held turn before the interrupt) or there is none, and the stop comes after that. Nothing closes the calls then. Claude Code does send the command's interrupted result. It comes after the stop reports, so it is output after the work's end, and the `session.cancelled` check of the user/assistant case drops it, as it drops everything after that. The raw stream, in the order Claude Code sends it: ``` task_updated agent patch killed task_notification agent stopped task_notification the command's task stopped user (ptu=agent) tool_result for the command, is_error <- dropped ``` ## Change - **A subagent's stop closes its open tool calls** (`closeStoppedSubagentToolCalls`), at `task_notification` `stopped` and at `task_updated` `killed`, after `finishTask` has reported the child idle. It closes the calls whose recorded parent is that subagent's Agent call (`Session.toolCallParents`) with the cancelled report that #1327 sends, naming the subagent so that every client form routes it like the call's other updates. - **Only where nothing else will end the calls**: a cancel is in effect (`session.cancelled`), and the client was told that the work ended (`workEndReported`: the prompt response on v1, `idle` on v2). While the work runs, a stopped subagent's calls get Claude Code's own result or `closeCancelledToolCalls` at the work's end, as before. - The loop of `closeCancelledToolCalls` is now `closeOpenToolCalls`, which takes the filter for the calls: the turn's closing, named `closedAtCancel`, skips a running background subagent's calls, and this closing takes one subagent's. These hunks are the same as in #1339, which closes the calls of a cycle that Claude Code started, so that the PRs merge in any order. - README: one sentence on when such a call ends. Nothing is closed twice: a closing forgets the call before it reports it, so a later closing, and the result that Claude Code sends after the stop, find nothing. The cancel settles a held turn and closes its calls before it interrupts Claude Code, so the stop reports always come after that closing. ## Per client form - **v1 without subagents:** the call goes to the root session, after the response when the cancel settled a held turn. - **RFD:** the call ends in the child's session right after the child's `idle` `cancelled`, as #1327 does at a turn's settle. - **AIR:** the cancel already ended every child, so the runtime drops the report (`ignoring late update for terminal subagent`). The call's state is released, which it was not before. - **v2:** as RFD. The root reports nothing, since it had no work. ## Evidence **Tests** (10 new): - `incomplete-tools.test.ts`: for a held turn and for no turn, the command ends once with the cancelled report, after the cancel's response, and the other subagent's command stays open; each of the two reports ends it alone; a subagent that completed after the cancel is left alone; one that stopped without a cancel, and one that stopped while the work still runs, get Claude Code's result, not a made-up report. - `acp-agent.test.ts`: the RFD form (the child's session, after its idle, after the response) and AIR (nothing reaches the ended child). - `acp-v2.test.ts`: the child's command ends `cancelled` in its session after its `idle cancelled`, and the root reports nothing more. **Removal checks.** Each of these fails at least one test: no closing at the notification (2), none at the patch (1), closing without a cancel (1), before the work's end is reported (2), at any status of the notification (1), of the patch (1), every subagent's calls (4), calls of another parent (7), the turn's closing no longer skipping a running background subagent (7), the report without the subagent's name (7), and the closing before the child reports idle (2). **Live**, 60 s command in a background subagent, cancel 4 s after its permission request was answered, every update validated against the SDK's JSON schema (0 violations): | client | cancel while | `main` | this PR | | --- | --- | --- | --- | | v1, no capabilities | the held turn waits for the subagent | `pending`, response `cancelled` | `failed` 4 ms after the response | | v1, no capabilities | no turn runs | `pending` | `failed` after the SDK's first stop report | | v1, RFD | no turn runs | `pending` in the child's session | `failed` in the child's session, after its `idle` `cancelled` | | v1, RFD | the held turn | not run on `main` | `failed` in the child's session, after the response | | v1, AIR | the held turn | not closed | report dropped by the runtime, state released | | v2 | root idle | `pending` in the child's session | `cancelled` in the child's session, after its `idle cancelled` | `npm run check`, `npm run build` and `npm run test:run` (2934 tests) pass. No golden file changes. With #1335 and #1339 merged into it, in any of the six orders, the branch merges without conflicts and all 2948 tests pass. ## For the maintainer - **Closing, not delivering.** Claude Code 2.1.296 sends the result, so delivering it after the work's end would also end the call, with Claude Code's text. I closed instead: 2.1.293 sent none for a subagent's call (#1327), the result comes after the response in the window #1313 closes, and closing works for both. The cost is the made-up text ("The turn was cancelled before this tool call returned a result.") in place of Claude Code's. ## Not covered - A background subagent that the interrupt does not stop keeps running, and its calls stay open. Its output after a cancel is dropped until the next prompt, as before. - A subagent that completes after a cancel: Claude Code's results for its calls were dropped, and the calls stay open. Nothing says they were cancelled, so none is reported. Delivering those results would end them. - A subagent that a SendMessage resumed: its calls carry the id of the call that launched it, while the registry holds the SendMessage id. `runsInBackground` has the same limit. - The calls of a cycle that Claude Code started on its own are #1339.	2026-10-14 11:45:36 +02:00
Ben Brandt	df21b3fb56	feat: restore a subagent from before a reload when SendMessage resumes it, for subagents RFD clients (#1332) ... After `session/load` or `session/resume`, Claude Code can resume an agent that ran before the reload: a SendMessage to it runs it again from its transcript. The adapter did not know that agent, so it was never exposed, and its activity was dropped. Now it runs in its session from before, the agent id, for every subagents RFD client: v1 clients that declare `subagents` and are not AIR, and every v2 client. ## What Claude Code sends From a live run, after a resume in a new adapter process: - `task_started` with the agent id, the **SendMessage** call's id as `tool_use_id`, and the message as `prompt`. - The resumed run's messages under `parent_tool_use_id` = the agent's **original Agent launch id**, from before the reload (the `toolUseId` in `subagents/agent-<id>.meta.json`), not the SendMessage id. - The SendMessage result with `resumedAgentId`, then `task_updated` / `task_notification` as usual. The runtime found no child for the agent id, and a SendMessage call establishes no parent, so the child waited for a parent that never came and was withdrawn when it ended. ## What changes - **The signal:** an agent that the runtime does not know, resumed by a SendMessage call that it saw. A new launch never counts: its `task_started` names an Agent or Task call. - **`subagentLineage`** (`subagent-history.ts`) reads the agent and its ancestors from the session's history, root first. The metadata names each launch call but not who made it, so a launch's parent is the session whose transcript has the call: the root's, or an agent's. That is the rule the replay (#1328) uses, so live restore and replay agree. An agent or ancestor the history cannot place gives an empty lineage. - **The runtime** (`NativeSubagentRuntime.restore`) registers the agent and its ancestors under their agent ids and their launch ids. Then it announces, parent before child, each ancestor that the client was not told about in this connection, as the RFD requires before the agent's traffic. An ancestor is announced with no work state, since nothing says that it runs. Then the agent, as `running`. From there the resume goes through the existing path (#1321): the SendMessage text is the child's `session_message`, and its end is `idle`. - **Unchanged:** an agent the history cannot place stays unexposed, as the RFD forbids guessing a parent. - **Load and replay:** after `session/load`, the replay has already announced the agent. The live resume announces it once more, as `running`, which repeats an association the client has (the RFD allows it). - **Refactor:** `subagentLaunchIds` moves from `acp-agent.ts` to `subagent-history.ts`, so the replay and the lineage find launches the same way. ## Evidence **Live, against Claude Code, with every update checked against the schema** (no violations): | Run | Result | |---|---| | v1, `session/resume`, SendMessage to a root-level agent | `subagent_update` running under its old id, the message from the root, its `PING` in its own session, `idle end_turn` | | v1, `session/load`, same | The replay announces it; the live resume after the response runs in the same session | | v1, `session/resume`, root → coordinator → echoer, SendMessage from the root to echoer | coordinator announced under the root with no state, then echoer under coordinator as running, its run in its session, its `idle` on coordinator | | v2, `session/resume` without replay, same nested session | as above; echoer also reports `running` and `idle` as its own `state_update`, coordinator has none | Before this change, the first run showed no `subagent_update` at all, and the child's `PING` was dropped. **Tests:** - `native-subagents.test.ts`: restore under the agent id, with routing by the launch id; ancestors first and with no state; an ancestor announced once for two agents; output that waited is delivered; restore at the SendMessage result alone; an agent the history cannot place or read stays unexposed; no history read for a new launch or a known child. - `subagent-history.test.ts` (real transcripts on disk): a root-level agent, a nested agent next to a sibling, an agent whose launch no transcript has, a nested agent whose ancestor no transcript placed, an agent without metadata. - `acp-agent.test.ts`: the agent's own runtime restores an agent from a history on disk, from the stream Claude Code sends. - **Mutation checks:** removing each of the 12 rules fails at least one test. `npm run check`, build and the full suite (2922 tests) pass, with no golden changes. ## Not covered - **AIR** is unchanged: this PR changes only the RFD form, so on AIR an agent from before a reload still stays unexposed. - **A fork** cannot resume an agent of the original session, since the SDK's `forkSession` copies no `subagents/` history.	2026-10-13 19:09:07 +02:00
Ben Brandt	21eef57655	feat: replay each subagent under its live session id for subagents RFD clients (#1328) ... A replay now restores subagents for a client on the [subagents RFD](https://github.com/agentclientprotocol/agent-client-protocol/blob/main/docs/rfds/subagents.mdx) form: a v1 client that declares `subagents` and isn't AIR, and every v2 client. Until now, its replay left children out. **AIR's replay is unchanged.** ## The rules The RFD asks that replayed children keep their original session ids and known parentage, and that announcements come before child traffic. It forbids guessing a parent or inventing an id, and asks that known gaps be made apparent. It also requires all selected history before the response. - **Ids:** each child replays under the session id it had live, the SDK agent id. Claude Code's `subagents/agent-<id>.meta.json` names the Agent or Task call that launched agent `<id>`. - **Order:** - The child is announced on the session that made the launch, right after the launch, with the same labels as live: the `name` and the role as `title`, and the short `description`. - Its own transcript then goes to the child session. - A nested child is announced on the child that launched it. - **Incoming messages:** the child's prompt is a `session_message` with the launch's id and the parent as sender, as live. A message that a SendMessage call delivered (`origin.kind: "coordinator"`) is matched to its call by the call's text. Claude Code frames it with a preface and an instruction, so the match checks that the delivered text contains the call's message. It then has the SendMessage's id, text, and sender, as live; without a match, its transcript id and the delivered text. - **Harness text:** other user text in a child's transcript, such as "[Request interrupted by user for tool use]", isn't shown, as the live child session doesn't show it. Tool results stay. - **Ends:** every child's end is an `idle` before the response. The end comes from the first of these that applies: 1. its last persisted task notification (its task id is the agent id) 2. `cancelled`, if `meta.json` says the user stopped it 3. its foreground launch's result (a background launch's result is only its launch) 4. otherwise, `idle` with no stop reason - **Gaps:** - A launch without metadata has no known id, so it isn't announced; its Agent call stays an ordinary tool call of the parent. A child whose transcript can't be read replays only its association, as the RFD allows. - Either case adds one notice for a client that takes notices: "Some subagent history is not available". - A subagent message that the session transcript stores inline is left out, since the child's history comes from its own transcript. Current Claude Code doesn't store such messages. - **v2:** a replayed child's messages are cleared before their first replayed chunk, as the parent's already are. A v2 client may still hold them. ## Changes in the code - **`src/subagent-replay.ts` (new):** `RfdSubagentReplay` holds the replay's children, deliveries, and ends. The replay loop in `acp-agent.ts` calls it at the launch, for each child message, and at the end. - **`subagentHistory`:** returns each launch's whole metadata record (name, role, description, background, stopped by the user). AIR and the RFD form share `readSubagentMessages`. - **The v2 bridge:** registers a child that a replay announces as replaying too. ## Evidence - **Live, v1:** I loaded a real Claude Code session from a live run: a foreground `scout` resumed once by SendMessage, and a background `sleeper` that a cancel stopped. - Both children replay under their live agent ids, with their labels. - `scout`'s prompt and its SendMessage delivery have exactly the ids and senders the live run used (`toolu_…HvPNZm` and `toolu_…cB3K9t`, from the root). - `scout` ends `end_turn`, and `sleeper` ends `cancelled`, from `stoppedByUser`. - **Live, v2:** the same session over v2 with replay. There were no v2 schema violations, each child's state is mirrored on its own stream, and all of it comes before the resume response. - **Tests:** - v1: a full replay order with a nested child, a matched delivery, dropped harness text, the ends, and the notice for a launch without metadata; ends for a stopped child and for one with no known end; inline subagent messages left out. - v2: a child's replayed message is cleared on the child session. - **Mutation checks:** removing any of the rules fails a test: - the v2 child registration - the RFD replay - the delivery match - the inline skip - `stoppedByUser` - ignoring a background launch's result - dropping harness text - the notice - **Golden files:** only the v2 `session-load-replay` changes. It gains the notice, because its Task launch has no metadata. The AIR golden files are unchanged. - **Checks:** `npm run check`, build and all 2886 tests pass. ## Not in this PR - **A SendMessage after a reload:** a SendMessage to an agent from before a reload still finds no known child in the live runtime, so the agent stays unexposed. A follow-up registers the replayed children, and the children of a resume without replay, in the runtime. ## Release Titled `feat:`, since a v1 client on the RFD form gets new replay output. Retitle it if you'd rather not release it.	2026-10-13 18:13:21 +02:00
Ben Brandt	53df1c7b22	fix: end the tool calls of a cancelled turn before it reports the cancel (#1327) ... ## Problem After `session/cancel`, a tool call that was still running never gets a final status. On `main` (Claude Code 2.1.293, a v1 client that declares no capabilities) all three of these stay `pending` for good: - the root's own Bash call, cancelled while its command runs; - a foreground Agent call; - the Bash call of that Agent's subagent, which this client sees as a root tool call with `_meta.claudeCode.parentToolUseId`. v2 has the same problem, and so does the subagents RFD form: the subagent's call stays pending in the child's session after the child reports `idle cancelled`. Found in the live run of #1257. ## Cause I recorded the raw SDK stream (`emitRawSDKMessages`) and the session transcripts of a live run on `main`. There are two gaps. 1. **The window drops Claude Code's interrupted result.** For the root Bash and the Agent call, Claude Code does send a result, inside the post-cancel window of #1309 and #1313, before the turn's `result`: a `tool_result` with `is_error: true`, stamped `non_execution_kind: "user-rejected"`, then `[Request interrupted by user for tool use]`, then the aborted result. The `if (session.cancelled) break;` in the `user`/`assistant` case drops it. 2. **The subagent's call gets no result at all.** Claude Code writes its interrupted result only to the subagent's own transcript (`<session>/subagents/agent-*.jsonl`). The stream never carries it, before or after the response, so no change to what the window delivers can reach it. Nothing else closes these calls. `closeUnfinished` runs only at `end_turn`, over the turn's `foregroundToolCallIds`, and that set holds none of the three: `task_started` removes a Bash or Agent call from it (`registerLiveTask`), and a subagent's call is never in it. ## Change Two rules, in the stream consumer: - **Deliver the real result.** Until the client is told that the stopped work ended (the prompt response on v1, `idle` on v2), the window delivers the `tool_result` of a tool call that the client holds open, with Claude Code's own text and `nonExecutionKind`. Only the tool call is updated. The other effects of a tool result (async tasks, plan state, the ExitPlanMode flow) stay dropped, and so does everything after that report, which is what #1313 closed. - **Close what has no result.** When a turn settles `cancelled` because of `session/cancel`, the adapter closes every tool call still open with `AcpToolCallRenderer.unfinished`, before it resolves the turn. That covers the subagent's call, a `tool_use` that Claude abandoned before it ran, and every call when the stream gives no results (the force-cancel backstop). Both protocols end the work at `turn.resolve`, so one rule serves v1 and v2. Supporting pieces: - The closing report names the subagent that made the call (`Session.toolCallParents`, bounded like `dispatchedToolCalls`), so the subagent runtime routes it with the call's other updates: to the child session in the RFD form (an idle child still takes updates), to no child that AIR ended, to the root for a client without subagents. - A **background** subagent that the SDK has not reported ended keeps its calls open. The RFD form lets a child run on through a cancel (`NativeSubagentRuntime.parentCancelled`). Two tests merged with #1320 failed against my first version, which closed those calls, and that is why the registry exists. A foreground subagent ends with the work that waits on it. - For a v2 client, an error result in the window is `cancelled`, whichever kind Claude Code stamps. CLI 2.1.293 stamps a command that the interrupt killed `user-rejected`, which `isAbortedToolResult` reads as a refusal (`failed`). A tool that finished as the cancel landed stays `completed`. A v1 client gets `failed`, as before, since v1 has no `cancelled`. - `unfinished` gets a `cancelled` variant: "The turn was cancelled before this tool call returned a result." - The rule applies to `session/cancel` only (`session.cancelled`), not to the ExitPlanMode "keep planning" outcome, which also ends a turn `cancelled`. - README: one sentence on what an RFD client gets at a cancel. ## Why both rules | | root Bash | Agent call | subagent's Bash | | --- | --- | --- | --- | | Deliver the real result only | fixed | fixed | **still pending** (no result in the stream) | | Close every open call only | fixed, made up | fixed, made up | fixed, made up | | Both (this PR) | Claude Code's result | Claude Code's result | made up | Closing alone would fix all three, but it throws away a result that Claude Code already sent: its text, and the `nonExecutionKind` that lets a client tell a rejection from an interruption. So the real result goes out where one exists, and the adapter makes up a status only for what Claude Code never reports. The Agent call ends first, then its subagent's call, in the same turn and before the response. ## What does not change - Output after the report stays dropped. A test pins that the tool of a prompt the cancel abandoned, which a permission request announces after the response, gets no result (it fails with the `workEndReported` check removed). - A result for a call the client does not hold open sends nothing and logs nothing. - AIR ends every child at the cancel, and the runtime drops every later update to an ended child. The closing reports go through the same routing and are dropped there, so nothing reaches an ended child (the live AIR run logs one `ignoring late update for terminal subagent`). - No golden file changes. None has a cancel, and the diff touches none. ## Evidence **Live** (Claude Code 2.1.293, Sonnet, each tool call's statuses before and after the prompt response; the probe allows each permission request after 1.5 s and cancels 4 s later, with `python3 -c "import time; time.sleep(30)"` so the command runs; every update is checked against the SDK's v1 schema): | | root Bash | Agent call | subagent's Bash | after the response | | --- | --- | --- | --- | --- | | `main`, plain v1 | `pending` | `pending` | `pending` | 0 updates | | this PR, plain v1 | `failed`, Claude Code's text | `failed`, Claude Code's text | `failed`, closed here | 0 updates, 0 schema violations | | this PR, RFD client | `failed` | `failed` | `failed`, in the child's session after its `idle cancelled` | 0 updates, 0 violations | | this PR, AIR | `failed` | hidden, as before | none: the child ended, and the runtime dropped the closing update | 0 updates | | this PR, v2 | `cancelled` | `cancelled` | `cancelled`, in the child's session, before the root's `idle cancelled` | 0 updates | The plain and v2 runs are on this commit. The RFD and AIR runs were on this change before it was rebased onto #1324 and #1325, which change the v2 subagent surface and the routing of a subagent's hook update, and not the cancel path. In the raw stream, the subagent's Bash has `task_notification stopped` and no result. Its transcript has the `is_error` result. **Tests** (16 new, one rewritten, one extended), scripted in the order recorded live: - `incomplete-tools.test.ts`, plain client: the real result of a running tool; an Agent call and its subagent's call; the force-cancel backstop; a start that streams in after the cancel; a result after the response; a stray result; an abandoned prompt's tool; a background subagent's call left open; a call that a permission request announced and a later update attributed; the registry's cleanup. - `acp-agent.test.ts`: the RFD form (the stopped child's call closed in its session, the running child's left open, the Agent call's result) and AIR (nothing to an ended child, including a permission-announced call). - `acp-v2.test.ts`: `cancelled` for the Agent call and its subagent's call before `idle cancelled`, `completed` for a tool that finished, and a cycle that Claude Code started. - `preserves cancellation and does not attribute its unfinished tool to the next turn` asserted that the cancelled turn's tool gets no `failed` update, which is the behavior this PR changes. It now asserts one report, before the cancelled response and not attributed to the next turn. **Mutation checks.** Each of these fails at least one test: no delivery of the real result (8), no closing at the settle (10), delivery after the report (1), delivery for calls the client does not hold open (1), closing a running background subagent's calls (3), no parent on the report (3), v2 real result not `cancelled` (2), `unfinished` not `cancelled` on v2 (1), the closing text (4), `ran` ignored (2), the registry kept after a call ends (1, added after the first run showed that nothing caught it), the parent recorded only from a `tool_call` (1), the v1 end-of-work signal on v2 (3), AIR's drop of updates to an ended child removed (5). `npm run check`, `npm run build` and `npm run test:run` (2898 tests) pass. ## Related, and not covered - #1221 closes the turn's `foregroundToolCallIds` at a cancelled settle with a made-up `failed`. It overlaps with this change in `settleActive` and in the test above, so the two will conflict. As far as I can tell from `registerLiveTask`, it would not have closed the three calls here. Its scenario, a start that streams in after the cancel, is covered by a test here. #1221 also hooks the inline settle of a held turn in `cancelTurns`, which this PR does not touch. - Not covered: a background subagent's calls when a cancel stops it while no turn settles (a cancel while idle, or of a held turn that `cancelTurns` settles inline); the calls of a v2 cycle that Claude Code started get Claude Code's results, but nothing closes the ones it sends none for. - The closing report carries no terminal exit, so a client that shows command output sees the command's call end without one. `closeUnfinished` does the same at `end_turn`. - A background subagent whose end the SDK reports only after the turn's result keeps its calls open. Claude Code 2.1.293 reports it before.	2026-10-13 18:10:14 +02:00
Ben Brandt	c7393d27ff	refactor: experimental ACP v2 support for subagents (#1325) ... Adds subagents to the experimental [ACP v2](https://agentclientprotocol.com/protocol/v2/overview) surface. With them, it covers v2's baseline session model, so this is the `feat:` that announces v2 support. The README gains a section on how to enable it and what it serves. Based on #1324, a v1 fix that this PR's golden scenarios exposed. Merge #1324 first; this PR then retargets to `main`. ## Experimental ACP v2 Started with `CLAUDE_AGENT_ACP_EXPERIMENTAL_V2=1`, the adapter serves the draft ACP v2 to a client that asks for protocol version 2 or later in `initialize`, and v1 to every other client, as before. - **Served on v2:** - the session baseline (`session/new`, `list`, `resume` with replay, `close`, `prompt`, `cancel`) - `session/delete`, `session/fork`, and additional directories - config options (the mode is one), plans, notices, compaction - display terminals for commands - permission requests, elicitation, providers, auth - and now subagents - **v1 only for now:** steering and the AIR extensions. The draft can still change, and the surface changes with it. ## What changes The [subagents RFD](https://github.com/agentclientprotocol/agent-client-protocol/blob/main/docs/rfds/subagents.mdx) makes subagent updates part of v2's baseline: "support is assumed rather than negotiated". - **Every v2 client gets subagents.** The v2 bridge declares `subagents` in the v1 request it makes for a v2 client (`v1InitializeRequest`), so the agent reports each Agent or Task subagent in the RFD form from #1320–#1322. - **The updates pass through:** `subagent_update`, `session_message` and `session_message_chunk` have the same shape in v1 and v2. - **The child's state goes to its own stream too.** v2 reports a child's work state on the child's own stream, mirrored on the parent. So a `subagent_update` with a `state` also becomes the child's `state_update`, sent right after the parent's copy (`v2ChildStateUpdate`). The announcement thus comes first, and both copies of a state come before any later one, as the RFD requires. This covers `requires_action`, and a failed child's `idle`/`error` with its JSON-RPC `error`. - **A state the RFD doesn't define throws,** as an update kind the surface doesn't translate already does. The SDK types the open members of v1's and v2's `StateUpdate` apart, so the bridge checks each state against the RFD's before passing it on. - **Replay doesn't flatten a child's inline text onto the root.** On replay, a subagent's text goes to the root only for a client that gets it there live: one without native subagent sessions that asked for the flattened transcript. Before, an RFD client (v1, and now v2) got the inline subagent text of a transcript replayed on the root, though the RFD form doesn't replay children yet. Current Claude Code keeps subagent messages in `subagents/`, not inline, so only the `session-load-replay` scenario's inline message showed it. AIR's replay is unchanged. ## Live run Against real Claude Code (Sonnet), with a v2 client that checks every `session/update` and permission request against the SDK's v2 schema, there were no schema violations: - **Launch:** - the child is announced on the root, then reports its own `running`, then gets its prompt as a `session_message` from the root - its tool calls arrive on its session, each with a title on its first report - the Agent call's 35-second heartbeat stays on the root - **Permission:** - `requires_action` appears on the child's stream and on the parent's copy, and on the root, whose turn waits on the child - the request goes to the child's session - then the child is back to `running` - **SendMessage resume:** - the same child session runs again, with the root as sender - the root turn goes idle while the resumed child keeps running, and the child reports `idle`/`end_turn` later, which v2 allows for background work - **Cancel:** the child is `idle`/`cancelled` on both streams, then the root is `idle`/`cancelled`. - A tool call still running at the cancel never gets a final status. That's a known bug on `main` for every client, fixed in a separate PR. ## Tests - **End to end on v2:** an Agent call whose child fails with an SDK error. Traffic arrives in order on both streams, and the child's `idle` carries `error: { code: -32603, message }`. - **Unit:** - the pass-through of the three updates - the child's `state_update`, and no copy for an association update without a state - the throw for a state and a stop reason the RFD doesn't define - **v2 golden files:** - the six subagent scenarios now show the RFD form: announcements, prompts, child sessions, both copies of each state, and permission requests on the child session - `session-load-replay` is unchanged from `main` - the scenarios also check every message against the v2 schema, and that each tool call's first report has a title (that check found #1324) - **Mutation checks:** each of these fails tests: - not declaring `subagents` - dropping the child's copy - sending it before the parent's - dropping the state check - dropping the replay rule - **v1 golden files:** unchanged. - **Checks:** `npm run check`, build and all 2882 tests pass. CI runs only on PRs to `main`, so I ran `ci.yml` on this branch by hand. ## Release Titled `feat:`, so its title becomes the release note that announces v2.	2026-10-13 16:57:14 +02:00
Ben Brandt	252126f616	feat: report a subagent as requires_action while its request is open for subagents RFD clients (#1322) ... The third of three stacked PRs that replace #1257. It's based on #1321, so its diff shows only the `requires_action` part. Merge #1320 and #1321 first; this PR then retargets to `main`. 1. #1320: the RFD form for a v1 client that declares `subagents` and isn't AIR. 2. #1321: a child keeps its session across SendMessage resumes. 3. **This PR:** `requires_action` while a child's request is open. **AIR is unchanged.** ## What changes The [subagents RFD](https://github.com/agentclientprotocol/agent-client-protocol/blob/main/docs/rfds/subagents.mdx) reports a child that waits for the user as `requires_action`. - **While a request is open:** a child whose permission or question request is open reports `requires_action` on its parent, then `running` again when its last open request ends (`NativeSubagentRuntime.awaitingUser`). The agent wraps the permission and elicitation requests of a child session in it (`withChildAwaitingUser`). - **Overlapping requests** keep `requires_action` until the last one ends. A child that ended while it waited doesn't report `running` again. - **A resume while a request is open** reports `requires_action`, not `running`. ## Live run Against real Claude Code (Sonnet), a child's Bash permission request showed `running` → `requires_action` while the request was open → `running` once it was answered. No schema violations. ## Follow-ups (low severity, not in this PR) - **Brief `running` after a withdrawal:** after a cancel withdraws a child's request, the child briefly reports `running` before the SDK's stop event. The same happens at a stream end, whose cleanup aborts every pending request. - **Ignored cancel requests:** AskUserQuestion's `createElicitation` is not raced against the abort. If a client ignores `$/cancel_request`, the child's open-request count stays up, and a later resume reports `requires_action`. ## Tests - **End to end:** `requires_action` around a child's permission request. The cancel test now also expects the background child's `requires_action` before the cancel. - **Runtime:** overlapping requests, a child that ended while it waited, and a resume with an open request. - **Checks:** `npm run check`, build and all 2877 tests pass on this branch, whose tree is #1257's with `main` merged in. CI runs only on PRs to `main`, so I ran `ci.yml` on this branch by hand.	2026-10-13 16:11:25 +02:00
Ben Brandt	bd06804b67	feat: keep a subagent's session across SendMessage resumes for subagents RFD clients (#1321) ... The second of three stacked PRs that replace #1257. It's based on #1320, so its diff shows only the resume part. Merge #1320 first; this PR then retargets to `main`. 1. #1320: the RFD form for a v1 client that declares `subagents` and isn't AIR. 2. **This PR:** a child keeps its session across SendMessage resumes. 3. #1322: `requires_action` while a child's permission or question request is open. **AIR is unchanged:** it keeps a new session per generation, as in its draft. ## What changes The [subagents RFD](https://github.com/agentclientprotocol/agent-client-protocol/blob/main/docs/rfds/subagents.mdx) gives a child one session id across every delegation to it. With #1320 alone, a resumed child stays `idle`. | RFD | With #1320 | Now | | --- | --- | --- | | One session id per child, across delegations | a resumed child stays `idle`, and its resumed work isn't shown | the child runs again in the same session, under the SDK agent id. The CLI runs a resumed agent under the SendMessage call's tool id, so that call becomes the child's current delegation: the resumed run's output and end reach the child | | The parent's message to the child is an incoming `session_message` | only the launch prompt | each SendMessage that resumes the child is a `session_message` with the SendMessage tool use's id. Its sender is the session that made that call, or left out when unknown. A repeated resume signal doesn't repeat it | Out-of-order events, from the reviews of #1257: - **Late end:** the end of an earlier delegation ends nothing (`isStaleEnd`). It also no longer settles the resumed run's live task at the agent level. - **Late result:** a SendMessage result that arrives after its run ended resumes nothing (`isEndedDelegation`). - **Early output:** a resume's output that arrives before its `task_started` is buffered, then delivered to the child. - **Reused id:** a run under an id the child used before ends the run, since the SDK falls back to it. - **Running patch:** a `task_updated` running patch reports `running` without its guessed prompt or call. ## Live run Against real Claude Code (Sonnet), a SendMessage to a finished child ran it again in the same session. Its message arrived with the SendMessage's id and the root as sender, and the turn waited for the resumed run. No schema violations. ## Tests - **End to end:** - a SendMessage resume under the SendMessage's tool id: one session, two prompts, the resumed output in the child, a stale end ignored - the resumed run's live task kept when an earlier delegation's end arrives late - a late SendMessage result - **Runtime:** - reuse and resume - a resume's output buffered before its `task_started` - the sender of a resume's prompt: the root, a child, or unknown - a run under a reused id - a running patch - a result without a text - **Mutation checks during #1257's reviews:** removing any of these rules fails tests. - **Checks:** `npm run check`, build and all 2873 tests pass on this branch. CI runs only on PRs to `main`, so I ran `ci.yml` on this branch by hand.	2026-10-13 16:11:25 +02:00
Ben Brandt	5758ac84a4	feat: report subagents as the subagents RFD defines, for clients that are not AIR (#1320) ... The first of three stacked PRs that replace #1257, split for review. Together they bring v1 clients the [subagents RFD](https://github.com/agentclientprotocol/agent-client-protocol/blob/main/docs/rfds/subagents.mdx), as revised by agentclientprotocol/agent-client-protocol#2281 and #2308. **AIR is unchanged**: its golden files don't change. 1. **This PR:** the RFD form for a v1 client that declares `subagents` and isn't AIR. 2. #1321: a child keeps its session across SendMessage resumes. 3. #1322: a child reports `requires_action` while its permission or question request is open. Merge them in that order. Each later PR is based on the previous branch, so its diff shows only its own part. ## Who gets what - **AIR** (any client that declares `_meta.jetbrains.air`): the earlier draft it implements, exactly as before. That's `subagent_spawned`, `subagent_state_update`, a session per generation, the hidden Agent/Task tool call, and draft replay. AIR keeps it whichever signal it declares. - **A v1 client with `clientCapabilities.subagents` that isn't AIR:** the RFD form below. SDK 1.8.0 types it (`subagent_update`, `session_message`, the v1 `StateUpdate`). - **Without either signal:** nothing changes. `subagentForm` (`src/acp-subagents.ts`) picks the form. `NativeSubagentRuntime` keeps the routing, buffering and nested lineage, and renders either form. ## The RFD form | RFD | Before | Now | | --- | --- | --- | | Announce the child before any of its traffic | `subagent_spawned { name, task, prompt }` | `subagent_update { sessionId, title, description, state: { state: "running" } }` | | `description` is the role or purpose, "not a transcript of instructions" | `task` was the prompt | `title`: the agent's `name`, with its role (`subagent_type`) after it, else the role. `description`: the Agent input's short `description` | | The parent's message to the child is an incoming `session_message` | `prompt` on the announcement | a `session_message` in the child's transcript, with the Agent/Task tool use's id and the session that made the call as sender | | Delegation tools stay tool calls | the Agent/Task tool call was hidden | it stays a tool call of the session that made it, with the report its model got. Its heartbeats and result stay there too | | Work-state snapshots, not a terminal lifecycle | `completed`, `failed`, `cancelled`, `disconnected` | `running`; `idle` with `end_turn`, `cancelled`, or `error` with the SDK's error text as its JSON-RPC `error`; `idle` with no stop reason for work that ended without a known reason (a worker restart, or still running when the stream ends) | | `idle` isn't terminal | later updates were dropped | an idle child still gets its updates, such as its background work's | | A cancel stops the work it waits on; other descendants are up to the Agent (#2308) | `session/cancel` ended every child as cancelled | the adapter ends no child itself. Claude Code's interrupt stops the foreground children, and currently background ones too; each reports `idle`/`cancelled` from the SDK's events, and the foreground ones' requests are withdrawn | | Never guess a parent | a child that ended before its spawning frame was announced under the root | it stays unexposed. A nested child waits for its parent's announcement | | Never move a tool call | | a tool call that a permission request emitted on the root before its child was announced stays on the root after a cancel. AIR keeps the cancel's cleanup, since its draft ends every child there | | No agent-side capability | `sessionCapabilities.subagents` for every client | for AIR only | ## Not in this PR - **SendMessage resumes** (#1321). Until then a resumed child stays `idle`. Requests find a child by its agent id, so only the permission and question requests of the resumed run appear in its session. A resume never opens a second session for the child, which the RFD forbids, and a test pins that. - **`requires_action`** (#1322). - **Replay** doesn't expose children yet. Today's replay invents `<session>:replay-subagent:<id>` ids, and the RFD requires the original ones. The RFD makes child replay a SHOULD, so an RFD client's replay leaves children out until the replay PR. ## Settled during the review of #1257 - **Cancel cascade:** the RFD leaves background children to the Agent (#2308). An agent-level test pins #2308's validation scenario. - **Session ids across forks:** the raw SDK agent id stays the session id. The SDK's fork copies no subagent history, so a fork can't repeat an id under another root. The reasoning is on `nextChildSessionId`. - **Held turns:** the adapter holds a v1 prompt open while a background subagent the turn started runs. A cancel still settles the prompt. ## Live run Against real Claude Code (Sonnet), with a v1 client that declares `subagents` and checks every update and permission request against the SDK's v1 schema, there were no schema violations: - **Launch:** `running` with the title (`scout (general-purpose)`) and description, the prompt as a `session_message` from the root, and the child's tool calls in its session. Then `idle`/`end_turn` before the Agent call completes on the root. - **A 40-second child:** the Agent call's heartbeat and result stay on the root. Before the fix, they moved to the child, because the heartbeat named the Agent call as its own parent. - **Cancel:** a foreground child is `idle`/`cancelled` 15 ms after `session/cancel`, and the prompt returns `cancelled`. Claude Code stopped a background child too (its metadata says `stoppedByUser`). - **Found on `main`, for every client, and fixed separately:** after a cancel, a tool call that was running never gets a final status. ## Tests - **AIR:** the end-to-end tests of the earlier draft run with an AIR client that declares `nativeSubagentSessions` (`AIR_NATIVE_SUBAGENTS`). The AIR golden files are unchanged. - **RFD, end to end:** - announcement and prompt - a failure with the SDK's error, also when the error arrives after the failure - a stop, and a worker-restart orphan - no draft updates - the cancel per #2308 - the raced tool call after a cancel, kept on the root, with AIR's cleanup kept - the Agent call's heartbeat Every update is checked against the SDK's v1 schema. - **RFD, runtime:** - the visible control tool call, also nested - labels, also from a late frame - an unparented child staying unexposed, and a nested child announced only after its parent - nothing reported at the parent's cancel - the end of the stream, and `unknown` - a resume opening no second session - **Plain/Zed comparison with origin/main:** it now allows the missing agent capability, which `compare.ts` documents. - **Mutation checks during #1257's reviews:** removing any of these rules fails tests. - **Checks:** `npm run check`, build and all 2863 tests pass. ## Release Titled `feat:`, because it changes what a v1 client that declares `subagents` receives.	2026-10-13 16:11:24 +02:00
nikita-ashihmin	190a00f68f	feat: answer /mcp in chat with the MCP server status and a reconnect (#1218) ... ## Summary In an ACP client, `/mcp` showed the CLI text "… Use `/mcp` in the terminal for details." The user of an ACP client has no terminal. In SDK mode, Claude Code also refuses `/mcp reconnect|enable|disable` with "Reconnect, enable, and disable aren't available in this session." and changes nothing. - `/mcp` and `/mcp reconnect|enable|disable [<server>|all]` still run as a normal Claude Code turn. The adapter replaces the text of the local command, through the same hook that `/usage` uses. Prompt order, cancel, and the provider update stay with the turn. - For an action, the adapter runs it in that turn through the SDK control API (`reconnectMcpServer`, `toggleMcpServer`). It shows one result line for each server, then the status list. - The status list comes from `query.mcpServerStatus()`. It has a summary line and groups by status: failed, needs authentication, connecting, connected, and disabled on one line. A failed server shows a short cleaned error. A list is used and not a table, because a table breaks words in narrow columns. - Useful CLI sentences stay, for example "There's no MCP server named …". Sentences that point to the terminal are removed. - After an explicit reconnect, a server from the ACP session that needs authentication starts the existing MCP OAuth flow, when the client supports URL elicitation. - `/mcp` is advertised with the input hint `[reconnect|enable|disable [<server>|all]]` and is hidden on history replay. ## Other commits in this branch This branch also carries commits of other work: skill command metadata for AIR, a faster `session/load` replay, and the resumed permission mode. They can move to separate PRs if preferred. ## Tests - `src/tests/mcp-command.test.ts` (61 tests). The fake CLI answers with the real SDK-mode texts and message shapes (synthetic assistant + result) and does not change any status. - A live run through the adapter with a broken and a working stdio server: `/mcp`, `/mcp disable good`, `/mcp enable good`, `/mcp reconnect broken`, `/mcp reconnect nosuch`. - `compare.ts` allows one new difference against the origin/main baseline: the `mcp` command in `available_commands_update`. The baseline files are unchanged. - `npm run check` and `npm run test:run` pass.	2026-10-02 17:37:59 +04:00
nikita-ashihmin	875d75f2a4	feat: AIR tool call contract, exact git patches, plan file, and fixes for every client (#1153) ... ## Summary One PR with separate commits (the earlier stack #1168 and #1169 is folded back in). ### Exact git patches - `src/diff.ts` builds exact git patches for Edit and Write: real line numbers, file modes, CRLF, the final-newline marker, a size limit (including a bound for `replace_all`), binary detection, and an asynchronous diff with a time budget. The approval preview mirrors the input normalisation of the bundled CLI. - No creation patch over an existing file or for an Edit of an existing empty file, and no patch for a Write that changed nothing. ### For every client Clients that do not declare `_meta.jetbrains.air` (Zed, plain ACP clients) get the same information as on `main`. - A `tool_call_update` omits top-level fields that did not change since the last report of the same tool call (ACP merge semantics). The `_meta` of each report stays complete. - Bug fixes: a failed approval preview no longer blanks the approval diff; a permission denial replaces a pinned approval patch; the compaction summary is not repeated when the streamed text is identical; streamed subagent text is not sent twice; async task fields are recorded only after a successful send; late updates of a finished native subagent are dropped; the updates of a fresh Claude context after a clear-context restart reach the ACP session. ### For AIR only - One fact in one field: input in `rawInput`, the file text of an edit only in the diff (`diffPatch`), output once, no display copies of the input (`rawInputRendering`), `_meta.claudeCode` reduced to `toolName`, `parentToolUseId` and the `toolResponse` markers, per-key `_meta` filtering. - Plan file mode (`planFile`): ExitPlanMode carries only `rawInput.planFilePath`; AIR follows the file that Claude writes. - AIR-only keys move under `_meta.jetbrains.air.*` and are no longer sent to other clients. ### Structure and docs - `src/tool-calls/`: one reporter per tool, one `ClientCapabilities`, one `AcpToolCallRenderer`, the field tracker and the changed-meta filter. - `docs/air-extensions.md` replaces the per-extension AIR docs. ## Tests - `npm run build`, `npm run check`, `npm run test:run`: 1995 passed. - Scenario tests for plain, Zed, and AIR clients: the SDK mock honours the adapter's session id, every update must reach its ACP session, every message is validated against the ACP JSON schema with all formats checked, plain and Zed are compared with a recorded `main` baseline, AIR keeps compact golden recordings.	2026-09-28 17:58:00 +04:00
nikita-ashihmin	2b666c3d35	feat: advertise recommended config values (#1111) ... Clients that negotiate the AIR `recommendedValue` capability receive concrete model and effort choices instead of ambiguous default rows. The SDK's default model is mapped only to an exact selectable model (including equivalent context suffix spellings); unavailable recommendations retain the legacy default. Recommendations remain independent of explicit selections. The adapter applies the displayed effort to the SDK at startup and on model switches, preserving supported user pins and re-reading per-model settings for automatic choices. Permission modes and clients without the capability retain their existing configuration behavior. Model and effort configuration logic is extracted into dedicated modules. Terse SDK model labels are enriched with concrete versions from model metadata: for example, `Fable` becomes `Fable 5.1`, `Sonnet` becomes `Sonnet 5`, and `Opus (1M context)` becomes `Opus 5`. Custom names are preserved, and collisions fall back to the original labels. An SDK version guard requires review on upgrades, and an opt-in live initialization test verifies the upstream model contract without sending a prompt. Validation: - `npm run check` - `npm run build` - `env -u ANTHROPIC_BASE_URL npm run test:run` — 1253 passed, 28 skipped - `RUN_INTEGRATION_TESTS=true npx vitest run src/tests/model-presentation.test.ts` — 4 passed - Regression coverage for unavailable model generations/context windows, startup effort, per-model settings, unsupported effort pins, and duplicate Opus labels	2026-09-10 01:10:31 +04:00
Andrey Bragin	0dd58685b1	ci: set up preview publishing (#1084) ... Today nothing reaches npm between two release-please releases, so trying a merged but unreleased change means building from source. This adds a continuously published preview channel. Every CI-green push to `main` that is not a release merge publishes `<package.json version, patch bumped>-preview.N` under the `preview` dist-tag, tags the commit `v<version>`, and dispatches the same agent registry update a stable release does. With `main` at 0.73.0 that gives `0.73.1-preview.1`, `0.73.1-preview.2`, and so on; `N` restarts at 1 whenever a release moves the base. `latest` is untouched. ## Approach - **Added to `publish.yml` rather than a new workflow.** npm binds a trusted publisher to one repo + workflow filename, and a package gets only one. A separate file would fail OIDC and cost the stable path its publisher. - **Gated on the `CI` workflow succeeding** (`workflow_run`), so a red commit is never published. release-please's release merge is excluded by the head commit's author and subject — its `releases_created` output is not reachable from a different workflow run. - **`N` is the max of the npm registry and local git tags.** npm reserves versions forever, even after `unpublish`, so a reused `N` is a hard failure; but the registry is CDN-served and lags, which the tags cover. A registry read failure aborts rather than guessing. - **Base is patch+1, not release-please's prediction**, which moves mid-flight and would reset `N` under already-published previews. - **The version is applied to the CI working tree only**, never committed — `package.json` and the release-please manifest stay release-please's to own. - **`--tag preview` is mandatory:** `npm publish` defaults to `latest` even for a semver prerelease. - **Three jobs.** `publish-npm-preview` mirrors `publish-npm` and only publishes (no repo write access); `publish-tag-preview` only tags, so a failed tag is retryable with _Re-run failed jobs_ without re-publishing an immutable version; `trigger-registry-update` is shared with the stable path. Both downstream jobs gate on a `published` output the publish step sets, not on job status — the tag push happens after the publish, so a red job can still mean npm has the version. ## Next step The publish is `npm publish --dry-run` for now. The `workflow_run` trigger and the `release` environment's protected-branch policy mean this job cannot run off the default branch at all, so merging this is the only way to exercise the trigger, the gate and the version calculation — and with `published` unset, the rehearsal neither tags nor touches the registry. Once one run looks right, a follow-up drops `--dry-run` and adds `echo "published=true" >> "$GITHUB_OUTPUT"` to that step. Nothing else changes.	2026-09-08 14:16:37 +02:00
nikita-ashihmin	14d192d108	feat: expose native subagents and async tasks (#1017) ... ## Summary - negotiate native ACP subagent sessions and AIR async task support - map Claude Agent/Task lifecycle to independent child session streams - publish background workflow, monitor, MCP, and backgrounded shell work as async tasks - attach background shell tasks to their originating tool calls so clients can update one command card and open its output log - stream task progress and preserve running, paused, completed, failed, and stopped states - keep synchronous shell work, generic tools, and task notifications out of user message chunks - preserve typed session failures and root permission/elicitation requests - preserve the legacy generic Agent/Task representation and flattened transcript opt-ins for clients without native subagent capability ## Compatibility The published ACP SDK does not yet contain PR #1992 types, so the change isolates the temporary structural cast in `src/acp-subagents.ts`. Clients that do not negotiate native subagent sessions retain the existing generic tool-call fallback, including the historical `_meta["subagent-transcript"]` capability and `forwardSubagentText` session option. Async tasks use the negotiated `asyncTasks` AIR capability and remain invisible to clients that do not advertise it. Claude does not expose a safe targeted child-cancel primitive, therefore child `cancel` and `close` capabilities remain disabled. ## Validation - `npm run check` - `npm run build` - `env -u ANTHROPIC_BASE_URL npm run test:run` (830 passed, 20 skipped) - `npm run test:run -- src/tests/async-tasks.test.ts` (5 passed) --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 14:11:13 +02:00
nikita-ashihmin	996d488589	feat: align Claude modes and clear-context planning (#1004) ... ## Summary - translate Claude SDK permission suggestions and tool-specific decisions into ACP v1 presentation and editable option metadata - align Claude session permission modes and clear-context plan handling - split permission effects, modes, normalization, option construction, presentation, and response handling into focused modules - document the permission extension and add unit plus live-audit coverage for native edge cases ## Tests - `npm run check` - `npm run build` - `env -u ANTHROPIC_BASE_URL npm run test:run` (931 passed, 27 skipped)	2026-08-22 14:59:03 +04:00
nikita-ashihmin	0581b9cf39	feat: align typed session failures with AIR protocol (#992) ... ## Summary - align `_meta.jetbrains.air.sessionFailure` with AIR's transcript-record protocol: `id`, `revision`, broad `category`, explicit `severity`, `title`, optional `details`, and `actions` - forward Claude's actual user-facing assistant/result text as `title`; use adapter-authored fallback text only when Claude provides no message (transport failure, worker EOF, or an internal invariant) - reduce categories to `connection`, `access`, `limit`, `request`, `service`, and `unknown` - limit suggested actions to `retry`, `login`, and `new_session` - update one transcript record through `id + revision`, keep resolved entries in history, and remove clear/tombstone updates - suppress duplicate assistant failure prose only for clients that negotiated typed failures; preserve legacy ACP behavior otherwise - restore synthetic usage-limit failures from session history with their exact stored Claude text - document negotiation, delivery carriers, identity/revision behavior, mappings, recovery, and compatibility in the extension spec ## Validation - `npm run check` - `npm run build` - `npm run test:run` — 777 passed, 26 skipped - `git diff --check` ## Tracking [IJAI-993](https://youtrack.jetbrains.com/issue/IJAI-993)	2026-08-14 17:29:39 +04:00
nikita-ashihmin	8b31dea11b	feat: expose provider-neutral ACP goal extension (#964) ... ## Summary - advertise a provider-neutral goal extension in `InitializeResponse._meta.goal` - map Claude SDK `active_goal` messages to `session_info_update._meta.goal` - expose the shared `_session/goal` control method with the truthfully supported `clear` action - document the extension as a candidate shape for a future first-class ACP goal API ## Architecture A goal is persistent **session state**, not the lifecycle of one `session/prompt` request. `goal.status === "active"` says that the objective may drive more work; it does not say that a prompt is executing now. This keeps two independent axes: 1. **Goal state** is published asynchronously as session metadata and may survive multiple prompt turns. 2. **Prompt activity** follows the backend's actual running/quiescent boundaries. While a turn runs, clients use advertised steering or prompt queueing. Once the backend is quiescent, an ordinary `session/prompt` is valid even if the goal remains active. The metadata is deliberately provider-neutral: ```json { "_meta": { "goal": { "version": 1, "controlMethod": "_session/goal", "actions": ["clear"] } } } ``` State is emitted as `session_info_update._meta.goal`; `null` clears it. The common snapshot vocabulary supports `objective`, common statuses, timestamps in Unix milliseconds, budgets/usage, iteration count, and a continuation reason. Each implementation emits only fields it actually knows. This shape is intentionally close to a future typed ACP capability/update so promotion out of `_meta` would not require a provider-specific migration. Control actions are capability-negotiated. The shared vocabulary reserves `set`, `pause`, `resume`, and `clear`, but an agent advertises only the subset it can implement with correct semantics. ## Claude mapping The Claude runtime already emits internal `active_goal` messages, although that message is not currently included in the public `SDKMessage` union. The adapter handles it before the exhaustive switch: - `condition` → `objective` - `iterations` → `iterations` - `set_at` → `createdAt` - `last_reason` → `lastReason` - `value: null` → `goal: null` Provider bookkeeping such as `tokens_at_start` is intentionally not exposed. Goal updates do not settle, extend, or otherwise mutate ACP prompt lifecycle. Claude's existing Stop hook remains authoritative for whether the backend itself continues working. Only `clear` is advertised for out-of-band control. It submits `/goal clear` through the existing session prompt queue, preserving the adapter's established ordering and turn ownership. Setting a goal remains available through `/goal <condition>` but is not advertised as a control action because it starts the long-running Stop-hook workflow. The companion Codex implementation is agentclientprotocol/codex-acp#371. ## Verification - `npm run test:run` — 692 passed, 20 skipped - `npm run build` - `npm run check`	2026-08-06 17:01:56 +04:00
nikita-ashihmin	8663170f18	Add structured Bash titles and nested subagent transcripts (#881) ... ## Motivation ACP clients currently have two gaps when rendering Claude Code activity: 1. Bash tool calls expose the shell command as the standard ACP title, but the concise human-readable `description` produced by Claude Code is lost. 2. ACP 1.2 has no standard subagent tool kind or nested-message relationship, so subagent prose and child tools are either flattened into the main conversation or filtered out entirely. This PR adds namespaced metadata and an explicit client capability so richer clients can render both cases without changing the standard ACP schema or regressing legacy clients. ## What changed ### Bash descriptions - Keeps the shell command in the standard ACP `title`, preserving command-oriented clients. - Exposes the optional Claude Code Bash `description` as `_meta.claudeCode.title`. - Applies the metadata consistently to eager permission tool calls, normal tool calls, and streamed input refinements. - Falls back to the command title when no description is available. ### Nested subagent transcripts - Adds the opt-in client capability `clientCapabilities._meta["subagent-transcript"] = true`. - Enables the Claude Agent SDK `forwardSubagentText` option when the client advertises support. - Preserves the pre-existing caller-provided `forwardSubagentText: true` option for compatibility. - Marks Agent and legacy Task launches with `_meta.claudeCode.subagent = true`. - Relates nested text, thinking, and child tool calls to the launching Agent/Task call through `_meta.claudeCode.parentToolUseId`. - Preserves parent attribution during session-history replay, not only during live streaming. - Handles nested Agent-to-Agent launches without inferring subagents from the generic ACP `think` kind. ## Compatibility Clients that do not advertise `subagent-transcript` retain the previous behavior: subagent text and thinking remain filtered from the top-level feed. The normal Agent/Task tool result is still emitted in every mode as the protocol-compatible fallback. No existing result or standard ACP field is removed or redefined. ## Validation - `npm run build` - `npm run check` - `npm run test:run` - 623 tests passed, 20 skipped Coverage includes live and replayed nested text/thinking, child tool attribution, Agent/Task launch markers, nested Agent launches, legacy filtering, and SDK-option compatibility.	2026-07-27 07:22:07 +00:00
Ben Brandt	b409782992	Update for ACP Org (#471)	2026-03-26 12:19:06 +01:00
Steffen Deusch	101f09dbf8	Add single-file executable using bun (#332) ... This adds a single-file executable using bun. The trick is to use a separate flag for ACP `--acp` and spawn the regular `cli.js` bundled by the Agent SDK if no flags are passed. This was, we can pass ourselves as pathToClaudeCodeExecutable.	2026-02-20 12:23:04 +01:00
Ben Brandt	0e77751692	Claude Code -> Claude Agent (#319) ... Update based on https://platform.claude.com/docs/en/agent-sdk/overview#branding-guidelines	2026-02-17 12:14:55 +01:00
Ben Brandt	3db76b2d20	Update clients list in readme (#228)	2025-12-30 21:51:22 +00:00
Forte Scarlet	db965a31aa	Change npm install command to global installation in README (#224) ... As mentioned in #216, npm installations should be global, but the documentation does not reflect this	2025-12-30 21:39:07 +00:00
Piet Brömmel	d19e399018	rename Claude Code SDK to Claude Agent SDK in the README und update the link (#220)	2025-12-18 22:27:09 +00:00
Ben Brandt	92c5cd84e8	Update clients list (#67)	2025-09-25 12:26:40 +00:00
Christian Tietze	8311a7a222	add Emacs client to README (#66)	2025-09-25 12:21:43 +00:00
Myles Scolnick	9ff7919ea4	readme: Add marimo notebook (#47)	2025-09-15 10:11:14 +02:00
Agus Zubiaga	5cd3ac91e8	Removing "Coming soon"	2025-09-08 13:18:28 -03:00
Xiangyi Li	96261a5b50	Remove dollar signs from CLI commands in installation section (#22) ... Makes it easier to copy and paste the installation commands without having to manually remove the dollar signs. This is a common convention in documentation to improve user experience when following installation instructions.	2025-09-03 22:01:24 -03:00
Oli	f70730f1ab	Update README for CodeCompanion.nvim (#17) ... Added CodeCompanion.nvim to the README, linking to my own setup instructions.	2025-09-03 12:53:40 -07:00
Agus Zubiaga	eb282abb50	Fix readme format	2025-09-03 11:39:33 -03:00
Agus Zubiaga	74c0be057b	Add npm badge	2025-09-03 11:36:39 -03:00
Agus Zubiaga	e66091f723	Add permission request note	2025-09-03 11:02:33 -03:00
Agus Zubiaga	f54da50bf5	Update README.md	2025-09-02 22:35:45 -03:00
Agus Zubiaga	28f36d7474	Format README	2025-09-02 18:24:51 -03:00
Agus Zubiaga	a07f132a9a	Improve "Other clients" section	2025-09-02 18:23:05 -03:00
Agus Zubiaga	7d969fd9ff	Update README.md	2025-09-02 18:17:17 -03:00
Conrad Irwin	03b51ae927	README v0	2025-08-28 15:20:53 -06:00