[BUG] Code tab in Claude Desktop hangs on "Sending..." forever — embedded CLI, chat tab, auth and MCP all work in isolation (Windows)

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?

What's Wrong?

The Code tab inside Claude Desktop accepts input and shows Sending... indefinitely. No response ever arrives. The timer keeps counting (observed past 1m 16s), and subsequent messages just queue up behind the first one.

The key point of this report: every individual component works when tested in isolation. Only the integration between the Desktop UI and the Code subsystem fails.

Component Result
Standalone CLI claude (2.1.238) Responds normally
Embedded binary shipped with Desktop (2.1.237) Responds normally when invoked directly
Regular chat tab in Desktop Responds normally
Authentication (/status) Valid — Claude Max account, session active
MCP servers 23 configured, load fine in CLI
Code tab in Desktop Hangs on Sending... forever

The embedded binary is not corrupt. Running it directly from its container path returns a normal response:
$cc = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code\2.1.237\claude.exe"
& $cc --version # -> 2.1.237 (Claude Code)
& $cc -p "just say: ok" # -> Ok.

So the process starts and reaches the API. It's the UI ↔ process bridge that never completes.

Steps to Reproduce
Install Claude Desktop on Windows 11 (MSIX, current installer).
Sign in. Confirm the regular chat tab works.
Switch to the Code tab.
Open any session (new or resumed) and send a message — even just hola.
The message shows Sending... and never resolves.
Expected Behavior

The Code tab returns a response, same as the CLI does with identical config and credentials.

Actual Behavior

Indefinite hang. Three additional observations that look like symptoms of the same failure:

1. No logs are ever written. The logs directory is created at app startup but stays completely empty:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs

Recursive listing with -Force returns zero files. This makes the failure undiagnosable from the user side and is arguably a bug in its own right.

1. No session is ever persisted. claude-code-sessions is created (timestamped 11:47:08, ~28s after main app startup) but remains empty. The Code tab never gets far enough to write a session record.

1. Credentials are never rewritten. %USERPROFILE%\.claude\.credentials.json keeps its original mtime across repeated Code tab login attempts. The existing token is valid, so nothing needs refreshing — noting it here only to rule out an auth-write failure, which was my initial hypothesis.

Process state during the hang
Id Name CPU WorkingSet64 StartTime
-- ---- --- ------------ ---------
2336 claude 35.7 187482112 11:46:40
3400 claude 0.0 35147776 11:46:39
3504 claude 100.0 548708352 11:46:40
5616 claude 1.2 144072704 11:46:42
6560 claude 6.8 71430144 11:46:40
15788 claude 0.1 103415808 11:46:42
20012 claude 80.6 250920960 11:46:39
29680 claude 0.7 125292544 11:47:08 <-- Code session
32164 claude 9.8 134438912 11:47:08 <-- Code session
36332 claude 0.2 87392256 11:46:40

PIDs 29680 and 32164 start ~28 seconds after the main app cluster (11:46:39–42), matching the creation timestamps of claude-code (11:47:06) and claude-code-sessions (11:47:08). PID 29680 sits near-idle at 0.7 CPU — alive but blocked, not spinning.

Environment
OS: Windows 11 Enterprise, 10.0.26200, x64
Claude Desktop: MSIX Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
Embedded Claude Code: 2.1.237
Standalone CLI: 2.1.238
Plan: Claude Max (Opus Plan)
Install type: MSIX, current-user, non-elevated → self-elevated
MCP servers: 23 configured (~750 tools total across them)
Ruled Out

Each of these was tested and eliminated:

Stale credentials — Credential Manager has no Claude entries at all; the CLI authenticates fine without them.
ANTHROPIC_API_KEY override — unset in both process and user scope.
MCP load stalling the session — claude -p with all 23 servers loaded responds immediately; claude --strict-mcp-config -p also responds. Not an MCP timeout.
Usage limit — a "approaching weekly limit" banner is visible in the UI, but both CLI paths return responses immediately, so the account is not throttled.
Heavy resumed session — happens on new sessions in different project folders too, not just large historical ones.
Corrupt install — reproduced after a full clean reinstall (package removed, container folder deleted, reboot in between).
Version skew between 2.1.237 and 2.1.238 — the embedded 2.1.237 responds correctly when invoked directly against the same ~/.claude state.
Background (likely separate, already tracked)

Reaching this state required a clean reinstall, because an in-place reinstall failed with AddPackage HRESULT 0x80073CF6. The AppX deployment log gave the underlying cause:

Error while deleting file \\?\C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\
SystemAppData\Helium\User.dat. Error Code : 0x20

0x20 is ERROR_SHARING_VIOLATION — the Helium registry hive was still mounted, so the installer couldn't clear the previous container. Only a reboot released it. The log also showed orphaned hardlinks from a previous version:

These hardlinks did not have packages in repository:
\Program Files\WindowsApps\Claude_1.30096.1.0_x64__pzs8sxrjxfjjc\app\LICENSE; ...

This matches #49655 / #49917 / #81907 and is mentioned here only as context for how the current install was produced. The Code tab hang persists on the resulting clean install, so I don't believe the two are related.

Suggested Priority

Two things worth separating:

The hang itself — blocks all use of the Code tab.
The empty logs directory — this is what makes the hang impossible to diagnose. Even if the root cause takes time to find, getting the Code subsystem to actually write logs would help everyone reporting this class of issue.

What Should Happen?

The Code tab should return a response, the same way the CLI does with identical credentials, MCP config and project state.

Additionally, the Code subsystem should write logs. The logs directory is created at startup but never receives a single file, which makes this class of failure impossible to diagnose from the user side.

Error Messages/Logs

Steps to Reproduce

1. Install Claude Desktop on Windows 11 (MSIX, current installer).
2. Sign in and confirm the regular chat tab returns responses normally.
3. Switch to the Code tab.
4. Open any session — new or resumed, any project folder.
5. Send a minimal message, e.g. hola.
6. The message shows Sending... and never resolves. Observed past 1m 16s;

subsequent messages queue behind the first one without ever being processed.

Verification that the underlying components are healthy (all of these succeed
while the Code tab is hung):

# Standalone CLI
claude -p "just say: ok"                        # -> Ok.
claude --strict-mcp-config -p "just say: ok"    # -> Ok.

# The binary the Desktop itself ships, invoked directly
$cc = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code\2.1.237\claude.exe"
& $cc --version                                 # -> 2.1.237 (Claude Code)
& $cc -p "just say: ok"                         # -> Ok.

The embedded binary responds against the same ~/.claude state the Code tab
uses, so the process and its config are fine — only the UI-to-process bridge
never completes.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.238

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_