[BUG] VS Code extension hangs forever on launch when workspace Python interpreter can't be resolved (usePythonEnvironment has no timeout)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

The VS Code extension hangs forever on launch — you type a message, the spinner spins, and Claude never responds — when the workspace's selected Python interpreter cannot be resolved by the Python extension. The claude subprocess is never even spawned, and nothing is surfaced to the user.

Root cause is a pre-spawn step with no timeout: spawnClaude(...) resolves the child environment before launching, and one of those steps is Python-env activation, gated by the claudeCode.usePythonEnvironment setting (default true). It does roughly:

// nhe(env): activate the workspace's Python env into the child env
const api = await getPythonExtensionApi();
const envPath = api.environments.getActiveEnvironmentPath(workspaceUri);
const resolved = await api.environments.resolveEnvironment(envPath);   // <-- no timeout

If resolveEnvironment(...) never resolves, the whole launch is stuck at this await before the claude process is spawned. There is no timeout and no fallback, so the tab hangs indefinitely.

In my case the selected interpreter was an x86_64 Python on an arm64 machine with Rosetta not installed (running it yields bad CPU type in executable). The Python extension could not introspect an interpreter it cannot execute, so resolveEnvironment hung, and the Claude launch hung with it. A stale/deleted interpreter, or any interpreter the Python extension can't resolve, would trigger the same thing.

Why it's invisible (second half of the bug)

The failure is completely opaque to the user:

1. The child process is spawned with stdio: ["pipe","pipe", <stderr>] where stderr is "ignore" unless DEBUG_CLAUDE_AGENT_SDK is set or an options.stderr callback exists — but in this case no process is spawned at all, so there's nothing to log.
2. The extension log shows Launching Claude on channel: <id> but never the subsequent Spawning Claude with SDK query function ... line. The gap between those two log lines is exactly binary/env resolution (resolveShellPath, then await nhe(...)).
3. Closing the tab logs generateSessionTitle failed: Error: Channel closed mid-launch, confirming the launch was stuck the whole time.

Note this is distinct from #45729, which attributes the pre-spawn hang to the interactive-shell PATH probe (/bin/zsh -lic ...). In my case that step succeeded (resolveShellPath: /bin/zsh -> 19 entries); the hang was specifically in the Python-env resolution. Same family ("resolution step hangs before spawn, no timeout, invisible"), different step. Same user-facing symptom as #54390 / #50983 ("claude process never appears in ps aux after 'Launching Claude on channel'").

What Should Happen?

1. Bound the pre-spawn Python-env resolution with a timeout (as resolveShellPath already is — it uses a 10s timeout). On timeout, log it and continue the launch with the un-activated environment instead of hanging forever.
2. Surface launch-phase failures to the user. A launch that stalls or fails during binary/env resolution should show an error (and ideally the reason), not an infinite spinner. Right now the process is never spawned, so neither stderr nor an exit code is ever produced — the user has zero signal.
3. Consider skipping Python-env activation when the resolved interpreter is missing or architecturally incompatible, rather than awaiting a resolve that can't complete.

Workaround

Set "claudeCode.usePythonEnvironment": false in settings — this short-circuits nhe(...) and the launch proceeds. (Or fix the workspace's selected interpreter so the Python extension can resolve it.)

Error Messages/Logs

Extension output channel (Anthropic.claude-code/Claude VSCode.log), every attempt:

[info] Launching Claude on channel: <id>
[info] resolveShellPath: /bin/zsh -> 19 entries
   ... (hangs here — "Spawning Claude with SDK query function" is never logged) ...
[info] Closing Claude on channel: <id>
[info] generateSessionTitle failed: Error: Channel closed mid-launch

Steps to Reproduce

1. Have the ms-python (Python) extension installed with claudeCode.usePythonEnvironment at its default (true).
2. In a workspace, get the Python extension to select an interpreter it cannot resolve — easiest reproduction is an interpreter of the wrong architecture (e.g. an x86_64 Python on Apple Silicon without Rosetta), or a symlinked interpreter whose base was deleted.
3. Open a new Claude Code tab and send any message.
4. Observe: infinite spinner, no response, no claude process spawned; log stops after resolveShellPath and never reaches Spawning Claude with SDK query function.

Setting claudeCode.usePythonEnvironment: false makes it work immediately, confirming the culprit.

Claude Model

N/A (never reached)

Is this a regression?

Introduced with the Python-env activation feature; related pre-spawn-hang reports start around 2.1.78 (#45729).

Claude Code Version

2.1.205 (Claude Code), extension darwin-arm64

Platform

Anthropic API (claude.ai / Max)

Operating System

macOS 26.5.2 (Darwin 25.5.0), Apple Silicon, Rosetta not installed

Terminal/Shell

zsh (/bin/zsh)

Additional Information

• VS Code 1.128.0
• Related: #45729 (pre-spawn hang via shell-PATH probe — same family, different step), #54390 / #50983 (same "process never spawns" symptom).
• The one-line mitigation on the extension side is to wrap the resolveEnvironment await in a timeout with a fallback, mirroring the existing resolveShellPath timeout.