## Summary Closes #1119. Supersedes #1120 by @amansk (their commits are included on this branch; the fork does not allow maintainer edits, so review fixes landed here instead). Hosts that never use `bypassPermissions` can opt a session out by sending `_meta.claudeCode.options.allowDangerouslySkipPermissions: false` on `session/new` (and again on `session/load`). When omitted or `true`, behavior is unchanged: bypass is available on non-root sessions. ## Design Bypass availability is decided once per session in `createSession`: ```ts const allowBypass = ALLOW_BYPASS && sessionMeta?.claudeCode?.options?.allowDangerouslySkipPermissions !== false; ``` and threaded to the three places that must agree: - the SDK `allowDangerouslySkipPermissions` flag (the actual enforcement; the CLI refuses bypass without it) - the spawn-time mode clamp in `resolvePermissionMode`, so a `permissions.defaultMode` of `bypassPermissions` (or a mode carried across a clear-context restart) becomes `default` before `query()` rather than failing at spawn - the session mode catalog in `SessionModeManager.initialize`, so the client is never offered a mode the CLI would reject ## Changes from #1120 - Fold the host opt-out into `resolvePermissionMode` via an `allowBypass` parameter instead of a second inline clamp; drop the separate `resolveAllowDangerouslySkipPermissions` helper - Make `allowBypass` a required `initialize` parameter and remove the module-global `ALLOW_BYPASS` fallback from `session-mode.ts` - Fix `tsc` errors in the new tests (`modes` is optional on `NewSessionResponse`), which broke the CI build job - Move the settings-driven clamp test onto the shared `acp-agent-settings` fixture (isolated cwd, no double module reload, passes as root) - Document the opt-out in `docs/permission-extension.md` ## Testing - `npm run check`, `npm run build` — pass - `npm run test:run` — pass (the branch is based before #1123, so the SDK version guard in `model-presentation.test.ts` only passes with the pinned 0.3.257; it clears on rebase) Co-authored-by: Cursor Agent <cursoragent@cursor.com> 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Amandeep Khurana <amansk@gmail.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
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)
- Following
- Edit review
- TODO lists
- Nested subagent transcripts
- Interactive (and background) terminals
- Custom Slash commands
- Client MCP servers
- Session-scoped long-running goals through the provider-neutral goal extension
- 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
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.
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).