6 Commits

Author	SHA1	Message	Date
Maksim Zheltoukhov	fe8b69edd4	feat: accept IDE session hooks without dropping model settings (#1265) ... IDEs can pass their own Claude hooks through `_meta.claudeCode.options.settings.hooks` on `session/new` and `session/load`. Before this change, any session settings replaced `CLAUDE_MODEL_CONFIG` entirely, so adding a single hook dropped the deployment's `modelOverrides` / `availableModels`. The two are now merged, and the session settings win per key. The wrapper does not merge hooks itself: Claude Code already runs the hooks of every settings tier, so user and project hooks keep running next to the session ones. Hooks stay scoped to their session, and a `session/load` with different settings recreates the query, which replaces or removes them. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 13:00:07 +02:00
nikita-ashihmin	03d84f6663	feat: add the AIR sessionIndex extension for fast session lists (#1268) ... ## Summary Adds the opt-in AIR `sessionIndex` extension. With it, an AIR client can show the latest sessions of a project quickly, with their state, and can rename, archive and unarchive them over ACP. The full contract is in `docs/air-extensions.md` ("Session index"). The extension follows ACP RFDs. The transport differs: it uses `_meta.jetbrains.air` request options and row fields, `_session/*` methods, and AIR capabilities that are not advertised under ACP v2. The `archived` list filter also differs (see below). - **Session list extensions** (agentclientprotocol/agent-client-protocol#2323): - `limit`, ordered by last user activity (`lastPromptAt ?? updatedAt`), and `includeWorktrees`. - Row fields `lastPromptAt`, `model` and `forkedFrom`. - `state`: `running`, `idle`, `requires_action`, and `error`, which the RFD lacks. - `lastTurnEndedAt`. - `cost`: the SDK's `total_cost_usd` for a session that runs on this connection only. No cost is read from transcripts. - Live updates come from an AIR list subscription (below). - **Session archive** (agentclientprotocol/agent-client-protocol#2161): - `archived` is on every row, `session_info_update` is sent on a change, and an unknown session is `-32002`. - The `archived` list filter has three values: `"unarchived"` (the default), `"archived"` (archived sessions only) and `"all"` (both, in one order). #2161 has a boolean here. Its `false` is `"unarchived"`, its `true` is `"all"`, and `"archived"` has no counterpart. - **Capabilities**: an AIR client that declares `sessionIndex` gets these in `_meta.jetbrains.air.capabilities`. The client declares only `sessionIndex`. - `sessionIndex`. - `sessionArchive`: `_session/archive` and `_session/unarchive`. The RFD capability is `archive` (#2161). - `sessionRename`: `_session/rename`. The RFD has capability `setTitle` and method `session/set_title` (agentclientprotocol/agent-client-protocol#1987). - `sessionListSubscribe`: `_session/list/subscribe`, `_session/list/unsubscribe` and `_session/list/changes`. No RFD counterpart. ### Clients without `sessionIndex` Clients that don't declare `sessionIndex`, which means non-AIR clients and released AIR builds, keep the current behaviour. They get the same SDK `listSessions` path, page size, cursor and initialize capabilities, with no watchers and no notifications. There are two deliberate deviations, both strictly safer: 1. **`session/delete` from an AIR client without `sessionIndex`.** Released AIR builds use delete as "Done". Instead of deleting the transcript (data loss), the adapter archives the session in AIR's own Claude format (below). Archived sessions are hidden from that client's list, so "Done" looks the same and nothing is lost. An unknown session keeps the SDK's error. Other clients get the SDK delete, as before. 2. **`session/close`** of a session that is not loaded here returns `{}` instead of throwing. ### Sessions open in another process `session/load`, `session/resume` and `session/prompt` work on a session that another live Claude Code process has open, for every client, as the Claude CLI does. Rename, archive, unarchive and delete also go ahead, writing records or deleting transcripts as the CLI's `/rename` and delete do. The other process keeps running. ### Archive format and rule The archive state uses AIR's native Claude archive format (`ClaudeStoreThreadBackend.appendTitleRecords`, ADR 0140), so AIR's native path and the adapter read and write the same state. - **Archive** appends `{"type":"custom-title","customTitle":"[archived] <title>",…}` and `{"type":"agent-name","agentName":"[archived] <title>",…}` to every transcript copy. **Unarchive** appends the same pair without the prefix. Titles are cut to the CLI's 200 characters. - **Archived is decided by the agent name first**, as in AIR's native Claude provider. A session's name is its last top-level `agentName`, else the custom title the SDK reports. The session is archived exactly when that name starts with `[archived] `. The listed title comes from the same source, shown without the prefix. - Title records are metadata: `updatedAt` and the list order do not move. ### Rename, archive and delete - **Rename** writes the same title pair. An archived session keeps its prefix. A session running here is renamed through its CLI's `rename_session` control request, serialised with auto-titling. Other sessions get the records plus the `custom-title.json` sidecar the CLI writes. No generated title replaces a client title, but a title stored later by someone else (a `/rename`) is still adopted. - **Archiving stops the running session.** `_session/archive` of a session loaded on this connection does four things: 1. It interrupts the running turn. 2. It retitles the session through its CLI. The adapter also appends the matching `agent-name` record to the CLI's transcript, because the CLI writes that record only later. 3. It closes the session as `session/close` does. 4. It archives the transcripts once more if the closed CLI left them unarchived. The client then gets `session_info_update` with `archived: true`. Unarchive does not reopen the session. A session that is not loaded here is archived by writing the title records. - **Delete** for a `sessionIndex` client deletes every copy of the session and its `<sessionId>/` directories. A session running here is closed first. ### Implementation (`src/session-index/`) - **Index**: - Reads the project dirs with `readdir` + `stat`, and keeps a 2000-entry metadata LRU keyed by (path, mtime, size). - Cache misses are read in parallel through `getSessionInfo`, plus a growing tail read (64 KB → 4 MB) for the last prompt, last message, turn end and agent name. - SDK semantics are kept: sidecar titles, `continued-in`, long-path hashes, darwin case, and first-prompt extraction (ported, and fuzz-compared with the SDK). - The `cwd` scope follows the SDK `listSessions`. Worktrees expand to the same relative subdirectory, and a session copied to several project directories is listed from its newest copy. - The keyset cursor is bound to `cwd`, `archived` and `includeWorktrees`. Session ids match exactly. - **State**: - For sessions of this process, the SDK state. - For other sessions, the Claude Code live registry (`~/.claude/sessions/<pid>.json`, with pid + procStart liveness and Claude Desktop's rules) or the transcript tail. The registry is read only for the row state. - `error` means the session is not running and its last turn ended with an error, not a cancel. Documented in `docs/air-extensions.md`, with an extension → RFD mapping table and the remaining differences. ### Measured on a real `~/.claude` (233 transcripts, read-only) | Case | New path | Old SDK path | |---|---|---| | cwd, limit 50, cold process | ~80 ms | 78–156 ms (all rows) | | cwd, limit 50, warm | 1.3–4 ms | — | ## Session list subscription Replaces polling the first page. It is only for a client that declared `sessionIndex`; the agent advertises `sessionListSubscribe` with it, never under ACP v2. - **Subscribe**: `_session/list/subscribe { cwd }` returns `{ subscriptionId }`. `cwd` must be absolute, else `-32602`; other params are ignored. - The scope is `cwd` and the same subdirectory in every linked worktree, in any archive state, without sidechains. - **Changes**: `_session/list/changes { subscriptionId, sessions, removed }`. - `sessions` holds the full `session/list` row of each session that appeared, or whose title, `lastPromptAt`, `state`, `lastTurnEndedAt`, `cost`, `model`, `forkedFrom` or `archived` changed since the last row sent. - The first change of a session after subscribe is sent in full. After that, a change of `updatedAt` alone sends nothing. - `removed` lists sessions that were deleted or moved out of scope. - Archive and unarchive are row changes. - A session is sent at most once a second, with one notification per subscription per pass. - **Unsubscribe**: `_session/list/unsubscribe { subscriptionId }` returns `{}` and is idempotent. - A subscription lives until unsubscribe or until the connection closes. - A connection has at most 128 subscriptions. The 129th is `-32602` with `data.reason: "too_many_subscriptions"`. - Subscriptions of the same `cwd` share one watch and are notified independently. - **Delivery** is best effort, with no resync and no sequence numbers. A rescan every 10 s (and 1 s after a project directory watch opens) sends whatever differs. - **Implementation** (`list-subscriptions.ts`, `session-info.ts`): - A non-recursive `fs.watch` on the scope's project dirs, the registry and the projects root. - A transcript event re-reads only that transcript, and a registry event reads only that `<pid>.json`. Sessions running here push their SDK state at once. - Subscribe reads no session row. The rescan reads only transcripts whose stat changed or whose read failed. ### Measured: one subscription on the 5,200-session project (Docker `node:22`, 2 CPU, 2 GB, shared host) 300 s of churn: 20 sessions appending 10/s each (updatedAt-only), registry status flips every 200 ms, and a session created every 2 s and deleted 10 s later. | | Old `list_changed` watcher | Subscription | |---|---|---| | Agent CPU p50 / max | 19% / — | 12.9% / 49% | | Event loop p99 (p50 / max of 1 s windows) | — | 16 / 31 ms; worst single delay 87 ms | | Change latency p50 / p95 | 950 ms (hint) | create 291 / 570 ms, delete 279 / 506 ms; registry state 902 / 990 ms* | | Notifications / min | — | 90 (896 rows, 0 rows for updatedAt-only appends) | | RSS | flat ~160 MB | 159 → 198 MB (heap flat ~50 MB) | \* The registry flips the same 5 sessions every 200 ms, so each is held to the once-a-second limit. Latency is measured from the first unsent change. These numbers were measured with an earlier subscribe that read every row up front. Subscribe now reads no rows, so that one-off cost no longer occurs. The lazy subscription has not been re-measured yet. ## Load test: 10,000 sessions (Docker, 2 CPU, 2 GB) Calibrated data: 10k transcripts, 15 GB, 36k subagent files, and one 5,200-session project. Sizes match a real profile (p50 311K / p90 2.67M / p99 20.5M). | Scenario (limit 50) | Before | After | |---|---|---| | Big project, first page cold / warm p50 | out of memory | 225 / 19 ms | | No cwd, cold / warm p50 | 1,722 / 178 ms | 209 / 45 ms | | Page through 4,637 rows | 457 s | 11.4 s cold, 2.9 s warm | | Delete p50 / 100 concurrent | 23.8 ms / 4.4 s | 7.8 ms / 0.8 s | | 300 s of churn (60k changes) | out of memory after 3 s | list p50 54 ms, 0 stalls >50 ms, RSS flat ~160 MB | ## Streaming: keep the event loop responsive under a backlog Under a backlog of buffered SDK messages, the adapter could freeze its event loop for seconds. Every `query.next()` on a non-empty SDK queue resolves in a microtask, so `runConsumer` forwarded the whole backlog without reaching a macrotask boundary. Incoming JSON-RPC, including `session/cancel`, waited until the backlog drained. 1. **Consumer yields to the event loop.** A shared `EventLoopYielder` (`src/utils.ts`) gives the event loop a turn via `setImmediate` once the current iteration has run for 8 ms. Order, content and cancel semantics are unchanged. 2. **No per-message copy in `nodeToWebWritable`** for byte streams. Object-mode streams keep the copy. 3. **Diff memo.** The approval preview and the PostToolUse patch no longer diff the same texts twice. Timed-out diffs are not remembered. 4. **Prefix guards** in `parseMcpCommand` and `sanitizeTitle`. Both give identical output. 5. **Replay yields between history messages**, with the same budget. With 10 sessions × 1 MB, the max event-loop delay went from 4205 ms to 1626 ms, and ping p95 from 2793 ms to 262 ms (interleaved A/B, Docker `node:22`, 2 CPU). Single-stream throughput is unchanged. Remaining stalls are inside the Claude SDK and GC. ## Test plan - [x] Rebased on `origin/main`. `npm run check`, `npm run build` and `npm run test:run` pass. - [x] Regression tests for the unchanged non-`sessionIndex` paths. - [x] Regression tests for every review finding. - [x] Reviews: Codex (gpt-6-astra) and a Claude review subagent, run as independent passes against `origin/main` until a round found nothing of normal or higher severity. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 01:59:47 +04:00
nikita-ashihmin	0e83a06c4a	fix: async task routing, Monitor tasks, structured task ids, and abandoned tool calls (#1249) ... It affects AIR clients with the `asyncTasks` capability. ## Problem - A subagent can start a background Bash or Monitor and then end its turn. The task ends after the subagent finished. The route of the task dropped every update of a finished child generation, so the client never got the terminal `async_task_state_update`. The task stayed running in the client forever. One AIR log held 440 such dropped updates. - The `Monitor` tool streams the stdout of a background command to the model only. The SDK reports its task as `local_bash`, so the client showed it as a background shell. In one real session, 18 of 18 Monitor tasks had no output file, no progress and no result. The Stop button only broke the agent's wait. - The adapter read a task id from the text of a Bash tool result. A foreground `sed`, `strings` or `python3` that printed adapter source, test fixtures or CLI strings became a background task, for example with the id `";\n const start = text` or `${e}`. The client got a spawn and a `backgrounded` marker on a foreground call, and the task never ended. - Claude Code 2.1.287 reports a background command in four texts, and only one gave an output path. A subagent tool result almost never has `tool_use_result` (0 of 48 in one session). So a subagent command that hit its timeout got no output path (9 of 10). ## Fix - `NativeSubagentRuntime.routeOfToolCall` still sends `async_task_spawned`, `async_task_progress` and `async_task_state_update` to the child generation that owned the tool call after that child finished. It never sends them to a later generation. Every other late update is dropped as before. The spawn is in the list because a held task can get its tool call id after the subagent finished. - `AsyncTaskRuntime` takes a `toolNameOf` lookup. A task of a `Monitor` tool call is ignored, like a subagent task: no spawn, no progress, no state, and no stop. A held task that gets its tool call id later goes through the same check. A `local_monitor` task is ignored too. The `Monitor` tool call stays in the transcript. - A task comes only from structured data: `tool_use_result.backgroundTaskId` or the SDK task events. The text id parser is gone. - The output path of a known task can come from the result of its own tool call. The path ends with `tasks/<id>.output` and starts after the nearest `": "` on the same line, so a path with spaces works, for example under `C:\Users\John Doe\AppData\Local\Temp`. It must be absolute (POSIX, a Windows drive or UNC), and it never holds the end of another path. The parse is linear in the text length. All four texts give the path in both event orders: the tool result before or after the SDK names the task. The memory is bounded. A structured path still wins, and the terminal `output_file` reaches the client also after a level close. - The `backgrounded` marker comes only from structured data: the structured task, a known background task of the tool call, or a `run_in_background` input. The "both event orders" above holds for the path, not for this marker. The marker rides the tool result update, so a command that the SDK names only after its tool result gets the marker only from a `run_in_background` input. A command that the user moved to the background by hand gets no marker in that order. - The replay behaves the same in each case. ## Tests - Native subagent and agent tests: a task update and a late spawn after the child finished go to `worker-1`; a held task of a subagent gets its spawn and state in the child session after the subagent finished; a late message chunk is still dropped; a subagent's background Bash ends after the subagent and the client gets the terminal state in the child session. - Monitor: runtime, live and replay tests, also a task that names its tool call after the tool result. A Monitor task cannot be stopped. - Structured ids: foreground output with each marker text creates no task; each of the four texts gives the path in both orders, also a Windows and a POSIX path with spaces and a UNC path; no path of another task, another tool call, `.outputs`, a relative path, a path without a `": "` boundary, or a path across a line; two paths on one line are not glued; a 2 MB text without `": "` parses in milliseconds; a structured path wins. An agent test covers a subagent without `tool_use_result`, and a replay test takes the path from the tool result. - The new tests fail without the change. Build, lint, format and all tests pass. ## Abandoned streamed tool calls This part affects every client, Zed included. **Problem.** The adapter opens a tool call at the `content_block_start` of a streamed `tool_use`. Claude can abandon that block before it is complete, for example for a steering message. The tool then never runs. At end_turn the settle check reported the session failure "Claude ended the turn without returning results for tool calls" (`incomplete_tool_call`). A real AIR session showed a red service error after 27 minutes of normal work, for a call that never had input. **Fix.** - The session records the tool calls that Claude Code sent to the tool runner: the `tool_use` blocks of a complete assistant message, and the tool calls of a permission request. The record is bounded and is dropped when the call ends. - At end_turn, an open foreground call without that record is abandoned. The adapter closes it as failed with "Claude stopped this tool call before it ran." and reports no session failure. The turn ends as `end_turn`. - An open call with that record keeps the old behaviour: the old failure text and the `incomplete_tool_call` session failure. - The cleanup and the cancellation checks are the same for both groups. - The replay does not change, because the history holds no partial `tool_use`. No scenario golden file changes, for AIR, plain or Zed. **Tests.** A partial `tool_use` and then text ends as `end_turn` with the neutral close. A mixed turn still fails for the unfinished call. A steering message during a partial `tool_use` gives no failure. The existing incomplete-tool tests now send the complete `tool_use` and keep their failure. The new tests fail without the change.	2026-10-05 18:59:32 +04: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
Kirill Alekhnovich	af0b43de94	fix: send the legacy custom answer key to AIR (#1210) ... Released AIR versions, such as 262.air/release-09, read the custom answer companion only from the root key _meta._askUserQuestionCustomAnswer. The adapter sent only _meta.jetbrains.air.customAnswer, so these versions showed the companion as a separate question. For an AIR client the companion now carries both keys with the same value. Other clients get no key, as before. Remove the root key when the ACP registry no longer serves AIR versions that read only that key. IJAI-2892	2026-10-01 13:25:01 +02: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