.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
The banner in VS Code says Error: Claude Code process exited with code 1, the chat panel goes dead and every prompt spins forever. The message itself is close to useless, and that's by design: it comes from the extension wrapping Claude Code, not from Claude Code. Anthropic's error reference states this outright. The CLI process the extension launched died with a generic failure code, and the reason it died went to a log you haven't read yet. This guide is the diagnostic flow I use to find that reason, followed by the fixes ranked roughly by how often they turn out to be the one.
Where the error comes from
The VS Code extension, the JetBrains plugin and any app built on the Agent SDK all run the claude CLI as a child process. When that child exits with a non-zero code, the wrapper has nothing better to show you than the code itself. Exit code 1 is the generic "something failed" value. By Unix convention, 127 would mean the command wasn't found at all, and 137 means the process was killed, usually by the kernel when memory ran out. Code 1 is the least informative of the three, which is why the flow below starts with reproducing the failure somewhere more talkative.
One detail that trips people up: the VS Code extension bundles its own private copy of the CLI inside the extension directory for the chat panel, and it doesn't add that copy to your PATH. The install troubleshooting doc calls this out. So the extension can break while your terminal install works, and the other way round. The terminal test that follows still splits the problem cleanly in two, you just can't declare the extension healthy because the terminal is.
Reproduce the error in a plain terminal
Open a regular terminal (not the VS Code integrated one at first, since it inherits some of VS Code's environment) and run:
claude --version
claude doctor
claudeThe first command should print a version line like 2.1.211 (Claude Code). The second runs the built-in diagnostics: install method, search binary, auto-update state. The third starts an interactive session. Two outcomes matter here.
If the CLI fails in the terminal too, the IDE is innocent and you have a broken install or a broken environment. Jump to the reinstall and environment sections below. If the CLI works fine in the terminal, the official guidance is that the problem is the IDE's environment: a missing or mismatched PATH, a stray ANTHROPIC_API_KEY or some other variable that differs between your shell and the process VS Code launched. That narrows things a lot.
Read the VS Code extension logs
Before changing anything, get the CLI's last words. In VS Code, open the Command Palette (Ctrl+Shift+P, Cmd+Shift+P on macOS) and run Claude Code: Show Logs. The extension's output channel carries the CLI's stderr, so the lines right before the exit usually name the culprit: an authentication failure, a missing binary, a config file it couldn't parse. The VS Code integration docs cover the extension's commands and their quirks; the JetBrains plugin has its own troubleshooting section in the official docs if you're on that side.
Read the log tail before posting anywhere. Half the GitHub issues about this error got closed for lacking exactly this information.
Update the extension and the CLI
This is the unglamorous fix that resolves a surprising share of cases, because several waves of this error were plain regressions. The 2.0.0 and 2.0.2 extension releases broke on Windows for many users (see issue #8557 for a representative report, complete with the error appearing right after a successful login), and the fix shipped in later versions. Update the extension from the Extensions view, then update the CLI:
claude updateIf the error started immediately after an extension update, the reverse move works too: right-click the extension, pick "Install Another Version" and drop back to the last one that worked. People in the issue threads used exactly this while waiting for patches. It's a workaround, not a fix, so retry the current version after the next release.
Check PATH and environment variables in the IDE
Applies to macOS and Linux mostly, where a GUI-launched editor doesn't always see what your shell profile exports. If credentials or PATH entries work in your terminal but not in the extension, the IDE process didn't inherit your shell environment. The install troubleshooting doc gives two remedies for this exact situation: set the variables in the IDE's own settings, or launch the IDE from a terminal where they're already exported (code . from the project directory does it).
This bites hardest with cloud provider setups. Bedrock and Vertex users see the CLI die on startup because AWS or ANTHROPIC_VERTEX_PROJECT_ID variables live in ~/.zshrc and never reached VS Code. Compare the two environments directly: run env | grep -i anthropic in your regular terminal and again in the VS Code integrated terminal, then look for differences.
Unset a stray ANTHROPIC_API_KEY
A leftover Console API key in your environment overrides subscription login once approved, and if that key is revoked or belongs to a disabled organization, the CLI errors out on startup. In the extension, all you see is exit code 1. Check and clear it:
env | grep ANTHROPIC
unset ANTHROPIC_API_KEYThen remove the matching export line from ~/.bashrc or ~/.zshrc, restart VS Code fully and run /status in a working session to confirm which credential is active. On Windows, check your user environment variables in System Settings and your PowerShell $PROFILE. The 400 "organization disabled" variant of this problem gets a fuller treatment in my Claude Code troubleshooting catalog.
Remove conflicting Claude Code installations
Ubuntu 24.04 example, though the same applies on macOS. If you've been using Claude Code since the early days, you can have up to three installs fighting each other: the native one at ~/.local/bin/claude, a legacy local npm install under ~/.claude/local/ and a global npm package. List what the shell sees:
which -a claudeMore than one line means it's cleanup time. Keep the native install and remove the rest:
npm uninstall -g @anthropic-ai/claude-code
rm -rf ~/.claude/local
curl -fsSL https://claude.ai/install.sh | bashThe last command reinstalls the native build, which needs no Node.js at all. If you insist on the npm route, current packages want Node 22 or newer. I covered the install methods and their trade-offs in the guide to installing Claude Code on Ubuntu, so I'll leave it at that here. Verify with claude --version and which claude pointing at ~/.local/bin.
Windows and WSL specifics
Windows machines produce this error through a few extra routes, mostly around which environment the binary lives in.
Exec format error on WSL1
If running claude inside WSL prints cannot execute binary file: Exec format error, you're on WSL1 and hitting a known regression with the native binary. The clean fix is converting the distro to WSL2 from PowerShell:
wsl --set-version <DistroName> 2Reports also exist of Agent SDK apps failing with exit code 1 on WSL2 with no such clear cause, so if you're wrapping the SDK there, test the same code on native Linux before blaming your own code.
Node and npm path problems in WSL
WSL imports the Windows PATH by default, so which npm can return a path starting with /mnt/c/, meaning WSL is running the Windows Node. An npm-installed Claude Code then fails with exec: node: not found or dies silently, and a VS Code window attached to WSL shows only the exit banner. Install Node inside the distro (nvm or the distro package manager) and confirm both which node and which npm return /usr/ or /home/ paths. VS Code itself adds a wrinkle: a WSL remote window runs the CLI inside Linux while a normal window runs it on Windows, and each needs its own working install. The full setup is in my guide to running Claude Code on Windows.
Git Bash detection on native Windows
On native Windows, Claude Code wants Git Bash or PowerShell. If Git is installed somewhere non-standard, point the CLI at it in settings.json:
{
"env": {
"CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
}
}The path has to end in bash.exe or sh.exe; the git-bash.exe launcher gets ignored. Endpoint security can also kill the spawned processes, in which case IT needs to allowlist claude.exe and the shells it launches.
Test with hooks and plugins disabled
If the CLI starts fine but dies mid-session (some reports describe crashes on the first follow-up message after a completed task), a customization is worth suspecting. Restart with everything disabled:
claude --safe-modeThat switches off plugins, MCP servers and hooks for the session. If the crashes stop, re-enable pieces one at a time until they return; a hook script that misbehaves on session events is the kind of thing that only shows up this way. For scripted -p runs, --bare does the equivalent isolation. I've written about hook debugging in the Claude Code hooks guide, including the exit-code semantics that make a hook block an action versus just logging.
Corporate proxy and TLS errors
Behind a TLS-inspecting proxy, the CLI can fail on its first API call while the extension shows only the exit banner. The log tail gives it away with certificate errors like SELF_SIGNED_CERT_IN_CHAIN. Point the CLI at your corporate CA bundle:
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pemSet it where the IDE will inherit it (see the PATH section above, same rules). Proxy variables HTTPS_PROXY and HTTP_PROXY follow the same logic.
Report the bug with logs attached
When nothing above fits, you've probably found a real bug, and this extension has had its share. The docs suggest a comparison method I like: run claude --debug in a terminal, reproduce the failure in the IDE, then diff what the two runs printed. File the result on the GitHub issue tracker with your OS, CLI version, extension version and the log tail from Show Logs, minus anything sensitive. Issues with that detail get fixed; the ones that just say "it doesn't work" get auto-closed, and there are plenty of those in the tracker already.
