### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? # VS Code Extension crashes on new session initialization with exit code 1 **Environment:** - **Version:** Claude Code 2.0.42 (VS Code Extension) - **OS:

## Confirming the issue on HPC login node ### Environment Details: - **Connection:** SSH to login node - **Claude install:** Native binary via `~/.local/bin/claude` - **Affected versions:** 2.0.36 through 2.0.49 - **Working version:** 2.0.35 ### Symptoms: When running `claude` in an interactive SSH session on the HPC login node: - Claude appears to start successfully (completes initialization) - No error messages displayed to user - Process exits silently after

[BUG] VS Code Extension crashes on new session initialization with exit code 1

Status Fixed / completed

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 7 comments · opened Nov 15, 2025 · closed Jan 7, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

VS Code Extension crashes on new session initialization with exit code 1

Environment:

Version: Claude Code 2.0.42 (VS Code Extension)
OS: macOS (Darwin 25.1.0, Apple Silicon)
VS Code: Latest version
Claude Plan: Claude Max

Description

The VS Code extension consistently crashes when attempting to start a new chat session, displaying the error:

Error: Claude Code process exited with code 1

Reproduction Steps

Open VS Code with Claude Code extension installed
Click to start a new Claude Code conversation
Extension immediately crashes with exit code 1

Observed Behavior

❌ New chat sessions fail to initialize
✅ Existing/resumed chat sessions work perfectly
✅ CLI version (claude command) works without issues

Debug Information

From ~/.claude/debug/latest:

[DEBUG] [Query.streamInput] this.sdkMcpTransports.size = 1
[DEBUG] [Query.streamInput] Entering Promise.race to wait for result
[DEBUG] [Query.streamInput] Timed out waiting for first result, closing input stream
[DEBUG] [Query] Calling transport.endInput() to close stdin to CLI process

The extension appears to initialize an MCP transport (size = 1) even when no MCP servers are configured, causing a timeout during session initialization.

Configuration Checked

✅ ~/.claude/.mcp.json is empty {}
✅ ~/.claude/settings.json has no MCP config
✅ Project .claude/settings.local.json has no MCP config
✅ Session cache cleared (~/.claude/session-env/)
✅ Extension reinstalled from scratch
✅ Extension state deleted (~/Library/Application Support/Code/User/globalStorage/anthropic.claude-code/)
✅ Project session files cleaned (168 → 10 files)

Workaround

Using the CLI version (claude command in terminal) works perfectly without any crashes.

Impact

Users cannot start new conversations in VS Code extension, forcing them to use CLI or resume existing sessions only.

Additional Context

This issue persists even after:

Complete uninstallation and reinstallation of the extension
Removing all MCP configuration files
Clearing all caches and session data
Testing in a clean directory

The fact that existing sessions work suggests this is specifically an initialization bug, not a general compatibility issue.

What Should Happen?

It should just open a new session
Like this:

!Image

Error Messages/Logs

Error: Claude Code process exited with code 1
Troubleshooting resources

Steps to Reproduce

Open a new session, and it will appear every time

!Image

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.42 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗

7 Comments

Xhulio-99 · 10 months ago

Confirming the issue on HPC login node

### Environment Details:

Connection: SSH to login node
Claude install: Native binary via ~/.local/bin/claude
Affected versions: 2.0.36 through 2.0.49
Working version: 2.0.35

### Symptoms:
When running claude in an interactive SSH session on the HPC login node:

Claude appears to start successfully (completes initialization)
No error messages displayed to user
Process exits silently after ~1 second
Exit code: 0 (success)

### Debug Log Output:
``[DEBUG] [Query.streamInput] Starting to process input stream [DEBUG] [Query.streamInput] this.sdkMcpTransports.size = 0 [DEBUG] [Query.streamInput] Finished processing 0 messages from input stream [DEBUG] [Query.streamInput] About to check MCP servers. this.sdkMcpTransports.size = 0 [DEBUG] [Query.streamInput] Entering Promise.race to wait for result [DEBUG] [Query.streamInput] Timed out waiting for first result, closing input stream [DEBUG] [Query] Calling transport.endInput() to close stdin to CLI process``

### Investigation:

Terminal has proper TTY: stdin.isatty() returns True
Terminal ioctls work: termios.tcgetattr(0) succeeds
File descriptors properly connected to /dev/pts/XXX
TERM=xterm-256color (properly set)
No VS Code extension running in my session
Issue affects multiple users on the same HPC system

### Workaround:
Downgrading to version 2.0.35 completely resolves the issue:

   curl -fsSL https://claude.ai/install.sh | bash -s 2.0.35

After downgrade, Claude starts immediately and works perfectly in interactive mode.

### Additional Context:
This appears to be specific to certain SSH/HPC environments where something in versions 2.0.36+ causes Claude to enter a waiting
state (possibly incorrectly detecting SDK mode or IDE connection?) instead of starting the interactive TUI.

The silent failure makes this particularly difficult to diagnose - the only indication is the debug log showing the timeout.

### Related Environment Variables Tried:

Setting CLAUDE_CODE_AUTO_CONNECT_IDE=false - no effect
Various TERM values - no effect
Clean environment with env -i - no effect

Would appreciate any insights into what changed between 2.0.35 and 2.0.36 that might cause this detection/timeout behavior in remote SSH environments!

Diginyx · 10 months ago

Thank you for this fix! I've been encountering the same issue. Downgrading to 2.0.35 worked for me as well.

developersteve · 10 months ago

I also have this same issue and I dont want to downgrade. Using Claude CLI via the terminal works as an alternative work around.

dkbush · 10 months ago

Is this issue related to https://github.com/anthropics/claude-code/issues/11910? In 11910, it has been found that a properly formatted managed-mcp.json file will cause the VS Code extension to fail as described in this issue.

tcvall86 · 10 months ago

Seems to be working again in 2.0.73 atleast

2025-12-18T06:50:59.557Z [DEBUG] [LSP MANAGER] Created manager instance, state=pending
2025-12-18T06:50:59.557Z [DEBUG] [LSP MANAGER] Starting async initialization (generation 1)

2025-12-18 07:50:59.558 [info] From claude: 2025-12-18T06:50:59.558Z [DEBUG] [LSP MANAGER] initializeLspServerManager() called

2025-12-18 07:50:59.558 [info] From claude: 2025-12-18T06:50:59.558Z [DEBUG] [LSP MANAGER] Created manager instance, state=pending
2025-12-18T06:50:59.558Z [DEBUG] [LSP MANAGER] Starting async initialization (generation 1)

2025-12-18 07:50:59.559 [info] From claude: 2025-12-18T06:50:59.559Z [ERROR] Failed to save config with lock: Error: Lock file is already being held

.
.
.

2025-12-18 07:50:59.560 [info] From claude: 2025-12-18T06:50:59.560Z [DEBUG] LSP server manager initialized successfully

2025-12-18 07:50:59.560 [info] From claude: 2025-12-18T06:50:59.560Z [DEBUG] LSP notification handlers registered successfully for all 0 server(s)

2025-12-18 07:50:59.560 [info] From claude: 2025-12-18T06:50:59.560Z [DEBUG] LSP server manager initialized successfully
2025-12-18T06:50:59.560Z [DEBUG] LSP notification handlers registered successfully for all 0 server(s)

siddhzx · 9 months ago

Why is this still active?

github-actions[bot] · 9 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.