Native Claude Code IDE integration (terminal CLI ↔ editor), like VS Code/JetBrains

[vitaly-andr]

Summary

Zed already supports Claude Code as an ACP agent in the agent panel. It does
not implement Claude Code's "IDE integration" protocol — the one the
claude CLI uses to attach to VS Code, JetBrains and Neovim. As a result,
running claude in Zed's integrated terminal cannot see your selection, open
editors, or diagnostics, and cannot show accept/reject diffs inside the editor.

Proposal

Implement the native IDE integration so claude in Zed's terminal connects to
Zed like it does to other editors:

• Lockfile discovery at ~/.claude/ide/<port>.lock (0600 in a 0700 dir).
• Local WebSocket transport authenticated via x-claude-code-ide-authorization,
  speaking JSON-RPC 2.0 / MCP (protocol 2024-11-05).
• Auto-connect by injecting CLAUDE_CODE_SSE_PORT + ENABLE_IDE_INTEGRATION
  into the integrated terminal.
• Tools: getCurrentSelection, getWorkspaceFolders, getOpenEditors,
  getDiagnostics, openFile, saveDocument, checkDocumentDirty, and a
  blocking openDiff (side-by-side, Keep/Reject).

Working implementation (fork)

I have a working implementation you can build and use today, until/if it lands
upstream:

• Fork: https://github.com/vitaly-andr/zed
• Branch: claude-code-ide-integration

git clone https://github.com/vitaly-andr/zed.git
cd zed && git checkout claude-code-ide-integration
cargo run --release -p zed   # Linux: run ./script/linux first

Open the integrated terminal, run claude — it auto-connects; editing a file
opens a Keep/Reject diff in the editor.

I'm happy to open a PR (linked below). Feedback on the approach and on UI
placement (currently a Keep/Reject notification) is welcome.

[ben-schreiber]

I would add that this is of great importance given the recent changes to Claude's billing which would charge ACP users at API rates. This would allow continued usage of Zed with the included Claude usage

https://zed.dev/blog/anthropic-subscription-changes

[rpearl]

I'm not familiar enough with Zed internals to say whether this should be merged as-is, but this should be taken as a great illustrative example of something that should be doable with an extension in the future (but isn't right now).

For practicality's sake I'm in favor of merging this or something similar. Inline diff reviews in particular are very nice to have compared to the TUI.

[vitaly-andr]

@rpearl Completely agree — this is a good stress-test for the extension API, and I'd love for it to be doable as an extension one day. The reason it can't be today is that almost every capability it needs lives below the extension boundary (WASM, sandboxed):

• Loopback socket + server — it binds 127.0.0.1:0 and runs a JSON-RPC 2.0 / MCP server over WebSocket (the protocol the claude CLI speaks). Extensions can't open a listening socket.
• Lockfile outside the project — discovery requires writing ~/.claude/ide/<port>.lock with 0600 perms inside a 0700 dir (honoring CLAUDE_CONFIG_DIR). Extensions are sandboxed to the project and don't control unix file modes.
• Terminal env injection — auto-connect works by injecting CLAUDE_CODE_SSE_PORT + ENABLE_IDE_INTEGRATION into processes spawned by the integrated terminal. There's no extension hook for the terminal's environment.
• Editor state + UI — the tools read the active selection, open editors and LSP diagnostics, and openDiff opens a blocking side-by-side accept/reject diff tab in the pane. None of that surface (diagnostics, diff tabs, pane integration) is exposed to extensions.

So this reads less like "should have been an extension" and more like a concrete wishlist for what the extension API would need to grow: a permissioned loopback-server capability, scoped filesystem access with mode control, a terminal-env hook, and editor diff/diagnostics surfaces. Until those exist it has to be native — but happy to refactor toward an extension-friendly boundary if the team wants to move that way.

And +1 on the inline diff reviews being the standout vs. the TUI — that was the part most worth getting right.

[nemith]

On neovim https://github.com/coder/claudecode.nvim this is amazing. Still allows claude code in a terminal but files and diffs are in neovim. With Terminal Threads i keep running into local edits clobbering each other, etc.

[vitaly-andr]

A few people asked about the security/footprint of the implementation in PR #58300, so to address it up front:

Current behavior: the server binds at workspace startup for every open window, whether or not you launch Claude Code. The exposure is intentionally contained and mirrors what the official VS Code / JetBrains / Neovim integrations do:

• Loopback only — it binds 127.0.0.1:0, so the OS picks a free ephemeral port and it is not reachable from the LAN or the internet. Only processes on the same machine can see it.
• Token-gated — every WebSocket connection must present a per-window random auth token (x-claude-code-ide-authorization header) or it gets a 401. The token lives in ~/.claude/ide/<port>.lock with 0600 perms (dir 0700), readable only by the user. The CLI discovers the port + token by reading that file; nothing else can connect without it.
• Cleaned up — the listener is torn down when the window closes, and the lockfile is removed on window close and on app quit (including a hard quit).

Honest caveats:

• It holds one ephemeral loopback port per open window even when idle (negligible, but real).
• The trust boundary is "any process running as your user" — such a process could read the lockfile and connect. This is identical to the official editor integrations, so it is not more exposed, but worth stating plainly.

Proposed improvement: add an explicit setting to control this, e.g. an enable/disable toggle and/or lazy binding (only start the server the first time Claude Code is actually used in a terminal, instead of at every workspace startup). Happy to implement whichever direction the team prefers — wanted to get the security model and the opt-out idea on the record before review.

[riverdale-msiegel]

Is this addressed yet? Just experimenting with claude code inside Zed terminal threads today and trying to figure out how to get /ide to work?

[uberjay]

I tried your fork and ran into a couple bugs (and a couple api changes), so pushed my own fork:

fork: https://github.com/uberjay/zed/
branch: claude-code-ide

Unsure if this is due to protocol/behavior changes, or something specific to my environment. It works well after the fixes!

Change: da3f460

    claude_code_ide: Make the CLI's WebSocket handshake succeed

    Three things kept `/ide` from connecting:

    - The lock file needs `useWebSocket: true`. The CLI picks between
      `ws://host:port` and `http://host:port/sse` from that flag alone and
      ignores `transport`, so without it the CLI dialed our WebSocket
      listener as an SSE endpoint.
    - The CLI offers the `mcp` subprotocol and abandons any connection whose
      `101` response doesn't select it, so echo it back when offered.
    - `BufferDiff::new` and `set_base_text` changed signatures upstream;
      update the diff-view call sites accordingly.

edit: unfortunately, it seems as though a lot of things don't work smoothly with my dev build of Zed, otherwise I would just use it. (e.g., I couldn't get other extensions, acp, agents, etc to work in my dev build.) The claude code IDE integration worked well, but there were too many other things that didn't, and I don't have time to figure it out!.