Claude Code IDE integrations: VS Code, JetBrains, and safe local context

What an IDE integration adds

Claude Code is an agentic coding tool that can read files, make edits, and run permitted commands. Its IDE integrations put the review surfaces next to the code: a plan or conversation, the file you are reading, a diff, and an integrated terminal.

That matters most for short feedback loops. You can select the failing function, ask a question about those lines, inspect a proposed change in the IDE's diff viewer, and reject it without translating the problem into a separate chat. It does not mean Claude automatically understands the entire product or has permission to use every system your IDE can reach.

The official VS Code extension and JetBrains plugin have different setup paths:

VS Code 1.94 or later is required for the native extension. Both integrations work with a paid Claude subscription or Claude Console account; third-party-provider setup has its own requirements. VS Code support also extends to Cursor and compatible forks. JetBrains support includes IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, GoLand, and Android Studio.

Use the context the editor actually provides

An IDE integration can reduce copy-paste, but “context sharing” should not become a vague promise. In VS Code, a selected range can be inserted as an @ reference. In JetBrains, the connected plugin passes the active selection and file path with prompts, and Claude can request the IDE's inspection diagnostics through its built-in ide MCP server.

Those features reduce the material you need to copy into a bug report. Review selected text before sending it; closing a tab alone does not remove the coding agent's filesystem access. In JetBrains, a Read deny rule can prevent a matching file from contributing both selected text and open-file context. The IDE server exposes diagnostics to the model, but does not expose a code-execution tool. Other configured shell or connector tools have their own access controls.

Use Manual mode when you want the IDE to show a proposed file diff before it is written. Auto and edit-accepting modes are useful only when their changed review point fits the task. In particular, Anthropic warns that JetBrains acceptEdits can modify IDE configuration files that the IDE may execute. Treat unfamiliar repositories, prompts, and configuration files as a reason to slow down, not to click through the warning.

VS Code setup and review workflow

Install the Claude Code extension from the Extensions view, then sign in the first time you open its panel. The Spark icon in the editor toolbar opens Claude for the active file; the Activity Bar opens the session list. You can move the panel, open a new conversation tab, and add a file or selected range to the prompt.

For a change you do not yet trust, start with a bounded request: “Explain why this validation returns an error for this selected input. Do not edit.” If the explanation is right, ask for a plan. In Manual mode, use the side-by-side diff to accept, reject, or edit the proposal. A clean-looking diff is still not a passing test, so run the relevant test and keep the result with the review.

If the extension does not appear after installation, reload the VS Code window. If you need the terminal command too, install the standalone CLI separately rather than assuming the panel's bundled copy is on your shell path.

JetBrains setup, remote development, and diagnostics

Install the Claude Code plugin from the JetBrains Marketplace, restart the IDE, and install the standalone CLI. Run claude from the project root in the integrated terminal; the plugin connects to that command. From an external terminal, start Claude and run /ide to connect to a running JetBrains IDE.

The project root matters because it is how the IDE session and Claude point at the same project. If the plugin cannot find claude, configure its full command path in the plugin settings. If /ide cannot find an IDE, check that the plugin is enabled and that the IDE has been restarted.

For JetBrains Remote Development, install the plugin on the remote host, not only on the local client. WSL 2 can need additional networking work because its default NAT network can block the local plugin connection. Anthropic documents a Windows Firewall option and mirrored networking; use that guidance for the machine you manage rather than opening an IDE server to a broader network by default.

The JetBrains plugin's local MCP server uses an ephemeral port and an authentication token. Its advanced setting can allow connections from all network interfaces, but Anthropic warns that this makes unencrypted session traffic and the token travel on the local network. Keep the default loopback setup when it works.

IDE integrations are not a permission shortcut

The IDE can make a local code task pleasant, but its terminal can still run commands, and its selected text can still contain secrets. Claude Code permission rules and your account's access controls continue to apply. A plan in a sidebar is not authorization to deploy, push, contact someone, or change a connected service.

Keep the boundary clear when work crosses into support operations. An IDE investigation can establish a useful technical fact, such as “the configured knowledge source is connected but its download is failing.” It cannot decide whether to change the source, retry a download, or tell customers that their knowledge is current.

Use eesel CLI from the IDE to investigate a failed knowledge sync

Suppose an engineer has an owner-approved incident note saying that a specific eesel knowledge source stopped updating. They open the team's own source-publishing configuration or sanitized export log in the IDE, if that material is available, and record the source name and time window. This does not assume access to eesel's internal sync code. They share only approved diagnostic excerpts with the coding session, not customer documents.

The support owner chooses the exact teammate that owns the source. From the IDE's integrated terminal, the engineer or an authorized coding agent can use eesel CLI to inspect the same teammate shown in the dashboard. Node.js 18.17 or newer is required for the npx form; every command returns JSON, which lets a person, script, Claude Code, Codex, or Cursor examine the evidence consistently.

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents

SYNC_REVIEW_AGENT="REPLACE_WITH_OWNER_APPROVED_TEAMMATE"
npx @eesel/cli status --agent "$SYNC_REVIEW_AGENT"
npx @eesel/cli integrations --agent "$SYNC_REVIEW_AGENT"
npx @eesel/cli integrations download list --agent "$SYNC_REVIEW_AGENT"
npx @eesel/cli activity --agent "$SYNC_REVIEW_AGENT"

login authenticates in a browser, so it is not a read-only preflight. Check whoami for the intended workspace, and replace the placeholder with the owner-approved teammate rather than relying on a remembered default. In an approved unattended environment, EESEL_API_URL and EESEL_API_TOKEN take precedence over stored credentials; EESEL_AGENT_ID can pin the target.

The output gives the owner evidence to act on: whether the expected integration is connected, which downloads are listed, whether the source appears ready, and what recent activity reports. It does not prove that a source has the right contents or diagnose a customer account. The engineer's IDE report should state the incident-note version, source identifier, observed status, relevant local error, and the decision still needed: retry, repair configuration, or escalate to the integration owner.

This investigation needs no chat or workspace write, so it does not require changing a live teammate's action settings merely to collect evidence. If the owner authorizes a repair, first read the relevant command's --help and preview supported writes with --dry-run. Apply only the approved change or retry, inspect download status again, and verify the source contents through the authorized source workflow. A preview does not repair a sync, and a successful download alone does not prove answer quality.

If a response test is needed afterward, the owner can choose a separate non-production teammate, disable consequential actions through Actions and Approvals, and approve the chat spend. Test a fact known to be in the revised source and inspect the actual response. Setup observations are free; chat is billed. Keep that evaluation separate from the earlier diagnosis and from any decision to resume customer-facing work.

Use eesel CLI when IDE evidence needs an owner decision

The IDE helps an engineer inspect available publishing code and logs. eesel CLI shows the selected teammate's current integration evidence in the same workspace as the dashboard. Together they give the owner a useful comparison: what the source system recorded, what eesel reports, and which questions remain before a repair. Neither surface alone proves the root cause.

Try eesel when you want that support handoff to be observable before it becomes a live change.