c1c8c0377d
Second part of step 4 of opt-in ACP v2 support (after #1231): the v2 surface now sends file changes as v2 diffs. Nothing changes on ACP v1: no v1 golden file changes. ## Why the agent builds them A v2 diff names each change's operation (`add`, `modify`, …) and can carry a `git_patch`. A v1 diff is a path with `oldText`/`newText`, and the agent often fills those with a snippet: an Edit's `old_string`/`new_string`, or one display hunk. So a v1 diff can't be translated. It says neither the operation (`oldText: null` can mean a new file, or a hunk with no old lines) nor where the lines are. So the agent builds v2 diffs itself, at the sites that build v1 diffs and know the change. The v2 surface creates the agent with `{ v2: true }`, which becomes `ToolCallClientCapabilities.v2`. A v1 client can't set it. This follows how the renderer already picks a form by capability, as it does for AIR's `diffPatch`. ## What a v2 client gets - **Live Edit and Write tool calls show no diff,** as a Write already does for AIR. The input holds a snippet, or doesn't say whether the file exists. - **The PostToolUse hook sends the exact patch** built from the written file. That's the existing AIR `diffPatch` path, which now produces either form. When it can't be exact, it falls back to a patch from the toolResponse: - a created file: `add` with its whole text; - an update: `modify` with the display hunks, which are fine for v2's renderable patch; - an update without hunks (previous content too large): the change alone; - an Edit with an empty `old_string`: no diff, since the response looks the same for a created file and a filled empty one. - **`git_patch` headers use absolute paths** without git's `a/` and `b/` prefixes, as the draft's example does: `diff --git /p/a.ts /p/a.ts`. ## Plumbing - The exported `toAcpNotifications` and `streamEventToAcpNotifications` take the agent's tool call capabilities (`toolCallCapabilities`) next to the ACP ones, which can't carry the v2 flag. External callers are unchanged. - The v2 diff travels through the agent as v1-typed content, with one documented cast in `v2DiffContent`. Nothing in the agent reads inside a diff item. - The v2 surface passes v2 diffs through and rejects a v1 diff, so a missed site fails loudly. That's how the scenario suite found the notification functions on the first run. - The approval preview stays AIR-only until v2 serves permission requests (step 5). ## Scenario suite `write-existing` passes, with an exact patch (golden file added). `write-new`, `edit-with-permission` and `edit-rejected` now stop at their permission request (step 5). No scenario stops at a diff any more. ## Verification - Unit tests cover the absolute-path headers, the live tool calls, the exact patch, and each fallback. - Each new rule fails a test when removed: git-style paths in a v2 patch, the v1 snippet for a v2 Edit, the AIR path for a v2 hook result, the notification functions ignoring the agent capabilities, and the missing guard for an Edit that created or filled a file. - Build, lint and all 2362 tests pass.
ACP adapter for the Claude Agent SDK
Use Claude Agent SDK from ACP-compatible clients!
This tool implements an ACP agent by using the official Claude Agent SDK, supporting:
- Context @-mentions
- Images
- Tool calls (with permission requests)
- Compact file changes through the negotiated AIR diff patch extension
- Following
- Edit review
- TODO lists
- Nested subagent transcripts
- Interactive (and background) terminals
- Custom Slash commands
- Client MCP servers
/mcpin the chat: the MCP server status as a list. The adapter runs/mcp reconnect,/mcp enable, and/mcp disablethrough the SDK control API, because Claude Code refuses them in SDK mode. A reconnect of an ACP server that needs authentication starts MCP OAuth through URL elicitation- Session-scoped long-running goals for AIR through the goal extension under
_meta.jetbrains.air.goal - Structured errors, recovery, and warnings through the opt-in session failure extension
- Concrete model and effort defaults through the opt-in recommended config value extension
- Tool permission presentation, editable choices, and durable effects through the permission extension
- One fact per field in every tool call report, as the ACP tool call contract defines
- All AIR extensions, capabilities, and
_metakeys: AIR extensions
Learn more about the Agent Client Protocol.
To try changes that have landed on main but are not released yet, install from the
preview channel — every push to main publishes one. See
docs/RELEASES.md.
npm install @agentclientprotocol/claude-agent-acp@preview
Subagent sessions
Subagents are exposed only after bilateral capability negotiation. Until the released ACP SDKs
preserve the draft clientCapabilities.subagents field, a supporting client may advertise
nativeSubagentSessions in _meta.jetbrains.air.capabilities; the adapter mirrors the capability
in its initialize response. The canonical field remains supported and takes precedence once it is
available. Without either client signal, Agent/Task lifecycle keeps its legacy ordinary ACP
tool-call representation and child interactions stay on the root session. Clients that use the
historical _meta["subagent-transcript"] capability or forwardSubagentText session option retain
the flattened child transcript behavior. See AIR extensions.
Contribution Policy
This project does not require a Contributor License Agreement (CLA). Instead, contributions are accepted under the following terms:
By contributing to this project, you agree that your contributions will be licensed under the Apache License, Version 2.0. You affirm that you have the legal right to submit your work, that you are not including code you do not have rights to, and that you understand contributions are made without requiring a Contributor License Agreement (CLA).