Error messages

Claude Code process exited with code 1

Claude Code process exited with code 1

This one doesn't come from Claude Code's own screen. It comes from the code that starts Claude Code for you: the Claude Agent SDK, the VS Code extension, the desktop app, or a GitHub Action. They all launch the claude program as a child process and talk to it over a pipe. When it quits with a non-zero exit code, the SDK throws:

Claude Code process exited with code 1

I found the line in the SDK's npm package (@anthropic-ai/claude-agent-sdk 0.3.282, which pairs with Claude Code 2.1.282), in a function called getProcessExitError. 344 issues in the anthropics/claude-code repo quote it word for word as of September 25, 2026.

Code 1 means the real error is somewhere else

Exit code 1 is the catch-all a program returns when it hits a fatal error. The SDK doesn't know which one, only that claude stopped. For a long time that was all you got, and the SDK's own issue tracker is full of people asking how to find out more.

Current versions tell you. In 0.3.282 the SDK keeps the last 2,048 characters the child wrote to stderr and tacks them on, so the message reads Claude Code process exited with code 1. stderr: … followed by the actual complaint. An SDK contributor said in March 2026 that this started in v0.2.75. If your message ends at "code 1" with nothing after it, you're either on an older SDK or claude died without printing anything.

For more, the SDK's query() options include stderr, a callback that receives everything the child prints, plus debug and debugFile. Setting the DEBUG_CLAUDE_AGENT_SDK environment variable does much the same and prints where it's writing the log.

Running as root with permissions bypassed

The most common single cause I found is a server or container running as root with permissionMode: "bypassPermissions". Claude Code refuses that combination on purpose. In the 2.1.282 binary the check prints this and exits with code 1:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

An Anthropic contributor closed the SDK issue about it with two ways out: run as a non-root user, or set IS_SANDBOX=1 in the environment you pass to the SDK. The code agrees, since the check only fires when the user ID is 0 and IS_SANDBOX isn't "1". It also skips Windows. Only set it if the machine really is a throwaway sandbox, since the whole point of the refusal is that root plus no permission prompts can wreck a system.

Other causes people have tracked down

In the VS Code debug terminal, an early SDK user found that VS Code's auto-attach injects NODE_OPTIONS into child processes, which broke the launch. The 0.3.282 SDK deletes NODE_OPTIONS before it starts claude, so current versions shouldn't hit that one.

Account trouble shows up here too, because the child can't start a session. On the October 2025 VS Code extension thread, one person fixed it by logging in to claude.ai, accepting a pending terms prompt, then running /login. In a GitHub Actions thread the answer was an API account that had run out of credit. Someone else traced theirs to an invalid session ID passed to resume, and on the SDK tracker a user found theirs after switching from an API key to a subscription.

If the SDK can't find or run the binary at all, you'll see a different message, such as Claude Code native binary not found at … or Failed to spawn Claude Code process. Those point at pathToClaudeCodeExecutable or the install rather than at anything inside a session.

The fastest way to see what went wrong

Run the same thing by hand. Open a terminal as the same user, in the same folder, with the same environment variables, and run claude. Whatever stopped the SDK's copy will usually stop yours too, except this time you'll see it: a login prompt, the root refusal, a credit balance error, a bad setting. It's how the reporter in that January 2026 SDK thread found their cause, by going back to the CLI to continue the same session.