[BUG] VS Code panel becomes permanently uninteractive

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 panel becomes permanently uninteractive after backing out of an active chat; root-caused to session stream not being released on back-navigation (Windows)

Environment

• Claude Code VS Code extension: anthropic.claude-code v2.1.143 (also confirmed in v2.1.142 and v2.1.141)
• Claude Code CLI: v2.1.143
• VS Code: stable channel
• OS: Windows 11 Pro 26200, win32-x64
• TUI renderer setting: default

Summary

When the Claude Code side panel opens an active chat and the user navigates back to the agents list (e.g., left-arrow), the panel's input handlers permanently lock — mouse wheel, clicks, keyboard input, and chat selection all stop responding. The lock persists after the underlying job completes (the "active turn" indicator stops blinking, but the panel does not recover). Only a full VS Code restart or Developer: Reload Window restores it.

Repro

1. Open the Claude Code side panel → agents view.
2. Click into a chat with an active turn in progress (yellow blinking-star indicator).
3. Press left-arrow (or otherwise navigate) back to the agents list.
4. Try to scroll the list, click another chat, or type to start a new chat — none respond.
5. Wait for the active job to complete (star stops blinking). Panel remains uninteractive.
6. Only recovery is Ctrl+Shift+P → Developer: Reload Window (~5s) or full VS Code restart (~30s).

Expected

Backing out of an in-progress chat should leave the agents-view panel fully interactive, regardless of whether the underlying job has completed.

Root cause (confirmed via process inspection)

When the panel attaches to a chat, the extension host spawns a foreground claude.exe launcher (parent = extension host PID), which connects to the local daemon. The daemon allocates a session process triple: foreground launcher + --bg-pty-host bridge + worker (--session-id <uuid> --agent claude).

On back-navigation, the panel does not release the stream to that triple. Its input handler remains blocked on the stream indefinitely.

Manually killing the panel's session triple unfreezes the panel without restarting VS Code or reloading the extension host:

taskkill /F /PID <foreground_launcher> /PID <pty_host> /PID <worker>

After the kill, the extension host auto-respawns a fresh foreground claude.exe, and the panel re-attaches cleanly. Confirmed reproducible.

This pins the bug to the panel-side stream lifecycle on navigation — not extension state corruption, not a UI-level deadlock, not an active-job race.

Auxiliary evidence

When closing a VS Code terminal running claude, the "Do you want to terminate running processes?" dialog appears even after the CLI session appears to have ended, consistent with worker pipes not being torn down on user-level navigation events.

Bisect

Identical behavior reproduced on extension versions:

• v2.1.143 (first install on this machine: May 16, 2026)
• v2.1.142
• v2.1.141 (oldest version on this machine: May 14, 2026)

Bug predates the user's sample range; the freeze was first noticed ~May 16 but may be older.

Ruled out during investigation

• Transcript size — archiving 102 MB of .jsonl from ~/.claude/projects/ did not help.
• Stale job directories — deleting a 21 MB orphan job dir from ~/.claude/jobs/ did not help.
• Third-party hooks — removing 11 lifecycle hooks (pixel-agents) from settings.json did not help.
• Third-party extension conflicts — no other Claude/AI extensions installed; uninstalled pixel-agents fully.
• Corrupted extension state — clean code --uninstall-extension + --install-extension did not help.
• Active-job blocking theory — symptom persists after job completes.
• Renderer mode — fullscreen renderer disabled (/tui default).

Severity

Easy to trigger — left-arrow is a natural back-navigation gesture. Forces a reload/restart every time. Severe interruption for users with multi-chat workflows.

Workaround (for users hitting this in the wild)

PowerShell script that kills the panel's session triple based on parent-process heuristics (newest foreground claude.exe whose parent is the extension host, plus its sibling --bg-pty-host and --session-id children of the daemon supervisor). Panel recovers in ~1 second without restarting VS Code:

# Identify daemon
$daemonPid = (Get-CimInstance Win32_Process |
    Where-Object { $_.CommandLine -like '*daemon run --origin transient*' } |
    Select-Object -First 1).ProcessId

# Newest foreground launcher (not daemon, not pty-host, not worker)
$victim = Get-CimInstance Win32_Process |
    Where-Object {
        $_.ExecutablePath -like '*\.local\bin\claude.exe' -and
        $_.CommandLine -notlike '*--bg-pty-host*' -and
        $_.CommandLine -notlike '*--session-id*' -and
        $_.CommandLine -notlike '*daemon run*' -and
        $_.ParentProcessId -ne $daemonPid
    } | Sort-Object CreationDate -Descending | Select-Object -First 1

# Triple = launcher + pty-host + worker spawned within 5s of the launcher
$siblings = Get-CimInstance Win32_Process | Where-Object {
    $_.ExecutablePath -like '*\.local\bin\claude.exe' -and
    ($_.CommandLine -like '*--bg-pty-host*' -or $_.CommandLine -like '*--session-id*') -and
    [Math]::Abs(($_.CreationDate - $victim.CreationDate).TotalSeconds) -lt 5
}

@($victim.ProcessId) + @($siblings | ForEach-Object { $_.ProcessId }) |
    ForEach-Object { Stop-Process -Id $_ -Force -ErrorAction SilentlyContinue }

What Should Happen?

Should be responsive

Error Messages/Logs

Steps to Reproduce

Start new chat with claude in VS Code terminal. Press left arrow to agents view. Stuck. Can see chat working with blinking star but can not interact

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

143

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_