# IDE and CLI coordination: run Claude Code beside your editor

URL: https://developertoolkit.ai/en/claude-code/build/ide-coordination/
Description: Run the Claude Code CLI beside VS Code, Cursor, JetBrains, or Neovim: split layouts, one writer per file, worktrees, and editor-side checks.

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](/en/claude-code/quick-start/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](https://code.claude.com/docs/en/vs-code), [JetBrains](https://code.claude.com/docs/en/jetbrains), [hooks](https://code.claude.com/docs/en/hooks), and [worktrees](https://code.claude.com/docs/en/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](/en/claude-code/quick-start/ide-integration/) 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:

```vim
set autoread
autocmd FocusGained,BufEnter,CursorHold * checktime
```

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

```vim
:vsplit | terminal claude
```

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

```bash
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](https://github.com/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`):

```lua
{
  "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**

```text
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:

```bash
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 or later (both release channels on 2026-10-12), interactive terminal and VS Code sessions start in auto mode, where a classifier approves most actions and Claude edits without asking. 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](/en/claude-code/quick-start/configuration/) 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`):

```json title=".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](/en/claude-code/automate/hooks-automation/) 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**

```text
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**

```text
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](/en/workflows/ship/evidence-bundle/) 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](/en/workflows/test/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](/en/claude-code/quick-start/ide-integration/).

**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](/en/claude-code/quick-start/ide-integration/): install the VS Code extension or JetBrains plugin, and fix connection problems.
- [Terminal mastery](/en/claude-code/build/terminal-mastery/): shell, keybindings, and terminal setup for long sessions.
- [Multi-file workflows](/en/claude-code/build/multi-file-workflows/): plan and verify changes that span many files.
- [Hooks automation](/en/claude-code/automate/hooks-automation/): turn more of these checks into hooks.
- [Claude Code desktop app](/en/claude-code/build/desktop-app/): a standalone window when you do not want Claude inside the editor.
- [Running agents in parallel](/en/ecosystem/agent-tools/parallel-agents/): several worktrees and agents at once, with the port and shared-state traps.
- In the other tools: [Cursor checkpoints and branching](/en/cursor-ide/build/checkpoints-branching/) and [Codex worktrees](/en/codex/automate/worktrees/).