IDE and CLI coordination: run Claude Code beside your editor

IDE and CLI coordination means running the Claude Code CLI beside your editor so the agent changes files on disk while the editor shows and checks those changes. In the VS Code, Cursor, or JetBrains terminal the CLI connects to the IDE automatically; from any other terminal, /ide connects it. It holds only with one writer per file.

This page is for developers who already have Claude Code running and want it working alongside their editor, not instead of it. A typical afternoon: Claude is refactoring the data layer in the terminal, you are finishing CheckoutForm.tsx by hand, and your editor’s completion is suggesting lines in the same file. Then you save over Claude’s edit, or Claude writes over your unsaved buffer, and nobody notices until a test fails. If you have not installed the extension or plugin yet, start with Claude Code IDE integration.

What a working IDE and CLI setup gives you

• A layout for your editor (VS Code or Cursor, JetBrains, Neovim with tmux) where Claude’s edits appear in the editor as they land.
• An ownership rule and a worktree pattern, so you, the editor’s AI, and Claude never write the same file at the same time.
• A PostToolUse hook that lints every file Claude edits and feeds the errors back to Claude before you look.
• Three copy-paste prompts: a fenced hand-off, a verification pass that uses the editor’s diagnostics, and a review guide that tells you where to look in the diff.
• Recovery steps for the six ways this setup usually breaks.

Commands and flags on this page were checked against Claude Code 2.1.283 (claude --help) and the official VS Code, JetBrains, hooks, and worktrees guides on 2026-09-26.

Which layout fits your editor?

The connection decides what the editor can do for you. A connected IDE shows Claude’s diffs in its own diff viewer, sends your selection as context, and lets Claude read its diagnostics through the mcp__ide__getDiagnostics tool. An unconnected editor only reloads files from disk.

Editor	How the CLI connects	What you get	How edits reach the buffer
VS Code, Cursor, other VS Code forks	Automatically in the integrated terminal; /ide from an external terminal; claude --ide connects on startup when exactly one IDE is available	IDE diff viewer, selection context, diagnostics	Built-in file watcher
IntelliJ IDEA, PyCharm, WebStorm, and other JetBrains IDEs	Automatically in the IDE terminal with the Claude Code plugin; /ide from an external terminal	IDE diff viewer (set Diff tool to auto in /config), selection context, diagnostics	Reload on focus, or Reload All from Disk
Neovim, Emacs, Helix, anything else	No official connection	Every CLI feature, no IDE tools	autoread plus :checktime (Neovim), or the editor’s revert command

VS Code or Cursor

1. Open the project folder, then open the integrated terminal with Ctrl+` (Cmd+` on macOS).

2. Split the terminal (Terminal: Split Terminal). Run claude in one pane and your dev server or test watcher in the other, for example npm run test -- --watch.

3. Drag the terminal panel to the right side of the window (right-click the panel title, Panel Position → Right) so the editor and Claude sit side by side at full height.

4. Run /ide in Claude. It shows the IDE connection status and lets you pick the editor window if Claude is not connected yet.

If you prefer the graphical panel, the VS Code extension shares history with the CLI: claude --resume in the terminal continues a panel conversation. The IDE integration guide compares the two.

JetBrains

1. Open the Terminal tool window (Alt+F12, or Option+F12 on macOS) in the project root and run claude.

2. Run /config and set Diff tool to auto. The entry only appears while the IDE is connected, so it doubles as a connection check.

3. Drag the Terminal tool window to the right edge of the IDE so the code and Claude are visible together.

4. If an external edit does not appear, use File → Reload All from Disk (Ctrl+Alt+Y on Windows and Linux, Cmd+Option+Y on macOS).

Neovim and tmux

Neovim has no official Claude Code integration (checked against the Claude Code 2.1.283 docs), so the CLI runs in a split and Neovim reloads buffers from disk. Add this to your config so buffers refresh when you move back to them:

set autoread
autocmd FocusGained,BufEnter,CursorHold * checktime

For a quick session, open a terminal split inside Neovim:

:vsplit | terminal claude

For longer work, give each tool its own tmux pane (run in your shell):

tmux new-session -d -s dev -c "$PWD"
tmux send-keys -t dev "nvim ." C-m
tmux split-window -h -t dev -c "$PWD"
tmux send-keys -t dev "claude" C-m
tmux select-pane -t dev -L
tmux attach -t dev

The community plugin coder/claudecode.nvim implements the same WebSocket protocol as the official extensions, which adds diffs and selection context inside Neovim. It is a third-party project marked beta in its README (read 2026-09-26), not an Anthropic product, so pin a version before you rely on it. To install it with lazy.nvim, add this spec (from the README’s Installation section; the README’s full example also maps cmd and keys):

{
  "coder/claudecode.nvim",
  dependencies = { "folke/snacks.nvim" },
  config = true,
}

Who writes which file?

The costly failures in this setup come from two writers touching one file. Your editor keeps an in-memory buffer; Claude reads and writes the file on disk. If you have unsaved changes when Claude edits the file, one of the two versions is lost. Decide ownership before each task, not after the conflict.

Work	Owner	Why
A change across several files, with tests run and fixed in a loop	Claude Code	It reads, edits, runs the test command, and retries without you switching windows
Shell work: git, package installs, migrations, log reading	Claude Code	Output lands in its context, so it can act on it
A two-line tweak in the file you are already in	You, with the editor’s completion	Faster than writing a prompt
Reviewing Claude’s diff, stepping through a debugger, checking a UI	You, in the editor	The editor is the better viewer; Claude has no screen
A second agent, such as Cursor’s own agent or Copilot’s agent mode	Treat it as another Claude	Same rule: its own files, or its own checkout

Two habits make the rule hold:

• Save before you hand over. In VS Code, File → Save All; in Neovim, :wa. The VS Code extension’s claudeCode.autosave setting (default true) saves open files before Claude reads or writes them, but a CLI in a plain terminal does not.
• Fence the task. Tell Claude which files it may touch and which you are editing. The prompt below does this.

Copy-paste prompt: hand off a task with a file fence

I am editing src/components/CheckoutForm.tsx by hand. Do not open, format,
or write that file.

Your task: move the order-total calculation out of src/api/orders.ts into a
new pure function in src/lib/pricing.ts, update every caller, and add unit
tests for it in src/lib/pricing.test.ts.

Rules:
- Only write files under src/lib/ and src/api/.
- If a change is needed in CheckoutForm.tsx, stop and tell me the exact
  edit instead of making it.
- Run the tests for the files you changed before you report back.
- End with the list of files you changed.

Give long jobs their own checkout

When Claude needs more than a few minutes, or touches files you also need, move it out of your working tree. --worktree creates a separate checkout under .claude/worktrees/<name>/ on a new branch named worktree-<name>, so Claude’s edits cannot reach your open buffers:

claude --worktree pricing-refactor

Open that folder in a second editor window to watch and review the work (for VS Code, code .claude/worktrees/pricing-refactor). Add .claude/worktrees/ to .gitignore so the checkout does not show up as untracked files in your main tree. A worktree is a fresh checkout, so it has no node_modules or .env until you install dependencies or list the gitignored files in a .worktreeinclude file. claude --worktree NAME --tmux also opens the session in its own tmux session (or iTerm2 panes when available). You merge the branch when the checks in the next section pass.

Auto mode edits while you type

With Claude Code 2.1.283 on the latest release channel, interactive terminal and VS Code sessions start in auto mode, where a classifier approves most actions and Claude edits without asking. The stable channel (2.1.274) runs about a week behind, so check the mode shown under the prompt rather than assuming it. In a checkout you are also editing, switch to Manual or Plan with Shift+Tab, or use a worktree. The configuration guide explains the modes.

How do you check Claude’s changes without reading every line?

The editor is where the evidence shows up: the Problems panel, the test output in the other pane, and the diff view. Set it up so Claude sees the same evidence first and fixes what it can before you look.

Lint every file Claude edits with a hook

A PostToolUse hook runs after each tool call. With exit code 2, its stderr goes back to Claude, so a lint error becomes Claude’s next task instead of your review comment. Add this to .claude/settings.json to share it with the team (it assumes a TypeScript project with ESLint and jq on your PATH):

.claude/settings.json

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r '.tool_input.file_path // empty'); case \"$f\" in *.ts|*.tsx) npx eslint --max-warnings=0 \"$f\" 1>&2 || exit 2 ;; esac"
          }
        ]
      }
    ]
  }
}

The hook lints only the file Claude just changed, so it stays fast in a large repository. If your editor does not show external changes, a personal variant in .claude/settings.local.json can open each edited file instead: replace the command with f=$(jq -r '.tool_input.file_path // empty'); [ -n "$f" ] && code -r "$f" || true (cursor -r in Cursor). The hooks automation guide covers formatters, blocking hooks, and the full event list.

Ask for a verification pass before you review

In a connected VS Code or JetBrains session, Claude can call mcp__ide__getDiagnostics to read the errors your language server reports. Do not count on Claude calling it after every edit; ask for it together with the test and type-check commands.

Copy-paste prompt: verification pass with editor diagnostics

Before I review, verify your changes:
1. Call the IDE diagnostics tool for every file you changed. Fix any error
   or warning you introduced; list any that were there before you started.
2. Run the type check and the tests that cover the changed files, using the
   commands in CLAUDE.md or package.json.
3. Run git diff --stat and confirm you changed only the files I allowed.
Report a table: file, diagnostics before and after, tests run, result.
If any command failed or was skipped, say so. Do not report success.

In an unconnected editor such as Neovim, replace step 1 with your compiler or linter command. Then check the evidence, not the code: the Problems panel is empty for the changed files, the test pane in your split shows the same pass Claude reported, and git diff --stat lists only the files in the fence. For the hunks that matter, let Claude tell you where to look.

Copy-paste prompt: tell me where to look in the diff

List the three hunks in your diff that are most likely to be wrong, with
file and line numbers. For each, say what behaviour would change if it is
wrong and which test (existing or missing) would catch it. If no test
would catch it, write that test now and run it.

Open those hunks in the editor’s diff view and accept or reject them there. On a team, the final sign-off is the CI gate on the pull request, not the local green run; the evidence bundle guide shows what to attach. Watch for one pattern: a test that turned green because Claude edited the test rather than the code. Protect the oracle explains how to stop it.

When IDE and CLI coordination breaks

The editor does not show Claude’s changes. VS Code watches the workspace by default; if a file does not refresh, run File: Revert File from the Command Palette and check that the path is not in files.watcherExclude. In JetBrains, run Reload All from Disk. In Neovim, run :checktime and add the autoread block above.

Your edit and Claude’s edit overwrote each other. You saved an old buffer over Claude’s change, or Claude wrote while you had unsaved work. Run git diff on the file to see which version survived. To undo Claude’s side, run /rewind (or press Esc twice on an empty prompt) and choose the checkpoint before the edit; checkpoints track only Claude’s file-edit tools, not Bash commands or your own edits, so use git restore or your editor’s local history for those. Then fence the task or move it to a worktree.

Claude reports “File has been modified since read”. Something changed the file after Claude read it: you, a format-on-save rule, or another agent. Claude has to reread it, which costs a turn and context. Stop editing that file while Claude works on it, or turn off format-on-save for the task and let the hook handle linting.

Diffs appear in the terminal, not in the IDE. The session is not connected. Run /ide; in JetBrains, also set Diff tool to auto in /config. If /ide says “No available IDEs detected”, follow the checklist in the IDE integration guide.

The hook slows every edit or blocks Claude in a loop. The command lints the whole project, or a pre-existing lint error keeps returning exit code 2. Scope the command to $f as shown, and fix or baseline existing errors before you turn the hook on.

The terminal pane is too narrow to read. Diffs and tables wrap in a thin split. Give Claude’s pane half the window, move the panel to the side instead of the bottom, or run Claude in its own tmux window and switch with the prefix key.

Where to go next with editor and terminal workflows

• Claude Code IDE integration: install the VS Code extension or JetBrains plugin, and fix connection problems.
• Terminal mastery: shell, keybindings, and terminal setup for long sessions.
• Multi-file workflows: plan and verify changes that span many files.
• Hooks automation: turn more of these checks into hooks.
• Claude Code desktop app: a standalone window when you do not want Claude inside the editor.
• Running agents in parallel: several worktrees and agents at once, with the port and shared-state traps.
• In the other tools: Cursor checkpoints and branching and Codex worktrees.