.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Claude Code runs in three editors through three different mechanisms, and knowing which mechanism you're dealing with explains most of the confusing behavior people hit. VS Code gets a native extension with its own chat panel and a bundled copy of the CLI. JetBrains IDEs get a plugin that wraps the CLI you've already installed. Zed treats Claude Code as an external agent speaking ACP (Agent Client Protocol) through an adapter. Same agent underneath in all three, different plumbing, and the plumbing is where the login and account questions live. Everything below reflects the 2.1 line as of August 2026.
Claude Code in VS Code
Install the extension
The extension is published as anthropic.claude-code and needs VS Code 1.94.0 or newer. Install it from the Extensions view by searching for "Claude Code", then open the panel via the Spark icon in the editor toolbar and sign in through the browser flow; any paid Claude subscription or a Console account works, no API key required. The full feature tour lives in the official VS Code documentation, and the parts worth the install on their own are plan review (plans open as editable Markdown you can comment on inline) and the diff view on proposed edits.
The same extension installs in Cursor and other VS Code forks, either from the editor's own extension search or from the Open VSX registry for forks without Marketplace access. Running Claude Code inside Cursor is a genuinely common setup; how that combination compares with Cursor's own agent is a separate discussion I've written up in Claude Code vs Cursor.
Check which account the extension is using
This is the question behind half the extension-related searches, usually right after a surprise usage warning. Type / in the prompt box and run /usage: recent versions open an Account & usage dialog showing the signed-in account, the plan and usage bars for the current session and week, with reset times. If the account in that dialog isn't the one you expected, you've found your answer faster than any settings spelunking would have.
The classic trap involves ANTHROPIC_API_KEY. VS Code launched from the dock or Start menu doesn't inherit your shell environment, so a key exported in ~/.bashrc may simply not exist inside the extension, and you'll be prompted to sign in even though "the key is set". Launch VS Code with code . from a terminal that has the variable and it inherits everything, or skip keys entirely and use the Claude account sign-in. Cuts both ways, mind: an inherited key that gets approved takes precedence over your subscription login, at which point your panel usage quietly bills the key. The /usage dialog is how you catch that too.
Log out and switch accounts
Open the Command Palette, type "Claude Code" and run the Logout command, then sign back in with the other account through the browser flow that follows. That's the entire switch, and it's the clean way to move between a personal Pro plan and a work Team account on one machine. If the sign-in screen doesn't reappear afterward, "Developer: Reload Window" from the same palette wakes it up.
Claude Code in JetBrains IDEs
The JetBrains story is a plugin named Claude Code [Beta], and the big difference from VS Code sits in the architecture: the plugin does not bundle a CLI. It launches the claude command in the IDE's integrated terminal and connects to it, so you install two pieces, the CLI first (on Linux that's the Claude Code install for Ubuntu, one curl command) and then the plugin from the JetBrains Marketplace, followed by an IDE restart. A "Cannot launch Claude Code" notification means the IDE can't find claude on its PATH; either fix the PATH or set the full binary path in the plugin settings under Settings > Tools > Claude Code [Beta]. IntelliJ IDEA, PyCharm, WebStorm, GoLand, PhpStorm and Android Studio are all supported.
Two keyboard shortcuts carry the integration. Cmd+Esc on macOS (Ctrl+Esc on Windows and Linux) opens Claude Code from anywhere in the editor, and Cmd+Option+K (Alt+Ctrl+K) inserts a reference to the current file and selection into the prompt, in the form @src/auth.ts#L1-99. With the plugin active you also get diffs in the IDE's own diff viewer instead of the terminal, your current selection shared as context automatically and the IDE's lint diagnostics fed back to Claude after each edit, which quietly fixes the "the agent can't see the red squiggles" problem.
Sessions started in an external terminal join the party with the /ide command, which connects a running CLI to the IDE and confirms with a message like "Connected to IntelliJ IDEA". One friction point I hit on a colleague's setup: JetBrains terminals sometimes grab the Esc key to move focus to the editor, which stops Esc from interrupting Claude. The fix is in Settings > Tools > Terminal, unchecking "Move focus to the editor with Escape". And for Remote Development, the plugin belongs on the remote host (installed via Settings > Plugin (Host)), not on your local client, an easy one to get backwards.
Claude Code in Zed
Zed has its own native agent, and Claude Code runs beside it as an external agent over ACP, using the @zed-industries/claude-code-acp adapter. You never npm-install that package yourself: open the agent settings (run agent: open settings from the command palette), go to the External Agents page, click Add Agent and pick Install from Registry, or jump straight there with zed: acp registry. Once installed, Claude appears in the new-thread menu of the Agent Panel. The setup is documented in Zed's external agents guide.
Login is where Zed users get stuck, so here it is plainly: authentication happens inside the agent thread, not in Zed's settings. Open a Claude thread in the Agent Panel and run /login, then authenticate with your Claude account or an API key. The gotcha Zed's docs call out explicitly is that an Anthropic API key configured for Zed's native agent does nothing for the Claude agent; each external agent owns its own auth, its own billing and its own model selection. Same reasoning applies in the other direction, so a working Claude login doesn't light up Zed's built-in assistant either. The Claude agent does read your CLAUDE.md files directly, though it won't inherit Zed-native profiles or instructions.
How the extensions relate to the CLI
Back to the plumbing, because this is where expectations break. The VS Code extension bundles a private copy of the CLI for its chat panel and does not add claude to your PATH. Installing only the extension gives you a working panel and a terminal that says "command not found"; installing the standalone CLI as well gives you both, and they share login, settings in ~/.claude/settings.json and conversation history. That last part is genuinely useful: claude --resume in the terminal opens a picker that includes conversations you started in the extension panel, and the whole resume machinery is covered in the guide to Claude Code sessions. The JetBrains plugin sits on the opposite architecture, running your installed CLI directly, so the CLI version and the plugin version update independently and claude update in any terminal upgrades what the IDE runs.
The bundled-copy design also explains the most-searched VS Code failure, the panel dying with "claude code process exited with code 1". Since the extension launches its own CLI process, anything that breaks that process (a stray environment variable, a conflicting install, a corporate proxy) kills the panel while the terminal might still work fine. There's a full diagnosis walkthrough in the guide to fixing the process exited with code 1 error. Windows adds its own wrinkles around PATH and WSL, which the Claude Code on Windows guide handles separately.
Terminal vs editor panel
My split after months of using both: the panel wins for interactive feature work, the terminal for everything else. Plan review as a commentable document, side-by-side diffs and @-mentions with line ranges are concretely better in a panel than in a TTY, and that's where I do work that needs my judgment every few minutes. The terminal keeps the full command surface (the extension exposes a subset of slash commands, and things like the ! bash shortcut and tab completion are CLI-only), survives inside tmux on a remote box and scripts cleanly. The nice part of the current design is that you don't choose once; the shared history means a conversation started in the VS Code panel this morning can continue in an SSH session tonight, and that round trip has become a normal part of my week.
