[BUG] Linux sandbox stuck on "Workspace still starting" forever on Windows 11 (Cowork/Code)

### 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?

In the Cowork / Code tab, the built-in Linux sandbox never finishes booting. Every bash command returns "Workspace still starting" and retries indefinitely (7+ attempts over several minutes). Normal startup should take 10–30 seconds, but mine never leaves the "starting" state.

### What Should Happen?

The Linux sandbox should boot within 10–30 seconds and bash commands should execute normally inside the isolated Linux environment.

### Error Messages/Logs

```shell
Every bash command returns:
"Workspace still starting"

Retried 7+ times over several minutes — same message every time.

Virtualization is Enabled (Task Manager → Performance → CPU).
WSL2 and VirtualMachinePlatform features both enabled via DISM, both returned "操作成功完成" (operation completed successfully):

PS C:\Windows\system32> dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
[==========================100.0%==========================]
操作成功完成。

PS C:\Windows\system32> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
[==========================100.0%==========================]
操作成功完成。
```

### Steps to Reproduce

1. Open Claude Code Desktop (running via a third-party gateway — bottom-left shows "duan0 · Gateway", model routed to deepseek-v4-pro) on Windows 11.
2. Go to the Cowork (or Code) tab.
3. Ask the assistant to run any bash command (e.g. `echo hello` or `sleep 1`).
4. Observe: it returns "Workspace still starting" and keeps retrying indefinitely; the sandbox never boots.

Already tried: enabled WSL2 + VirtualMachinePlatform via DISM, confirmed Virtualization=Enabled in Task Manager, fully quit & relaunched the app, restarted PC multiple times. None fixed it.

### Claude Model

Other

### Is this a regression?

I don't know

### Last Working Version

N/A — the sandbox has never started successfully on my machine.

### Claude Code Version

2.1.178 (Claude Code)

### Platform

Other

### Operating System

Windows

### Terminal/Shell

PowerShell

### Additional Information

IMPORTANT CONTEXT — I am NOT using the official Anthropic backend, and I am behind a proxy.

1) THIRD-PARTY GATEWAY: My Claude Code Desktop is connected through a provider-switching tool called "CC Switch" (screenshot attached). It lists two providers:
- "Claude Desktop Official" (https://claude.ai/download)
- "DeepSeek" (https://platform.deepseek.com) — currently ACTIVE, tagged "需要路由" (routing required).
So my client is routed to the DeepSeek provider via CC Switch, NOT the official Anthropic backend. The bottom-left of the Claude Code UI confirms this: "duan0 · Gateway", model routed to "deepseek-v4-pro" (a non-Anthropic model).

2) PROXY / NETWORK: I am in mainland China and use "FlClash" as my proxy client (screenshot of its dashboard attached). Current state:
- System proxy: ON
- Outbound mode: "Rule" (规则)
- Network check resolves to a US IP (23.156.152.24), so outbound connectivity to overseas servers IS working through the proxy.
- TUN / virtual NIC: OFF.
This means general internet access (including to US endpoints) is available via the proxy — so a pure network block is unlikely to be the sole cause. Note however that the sandbox/WSL2 traffic may not automatically inherit the host's system proxy, which could still prevent the VM image download even when the browser works.

ROOT CAUSE HYPOTHESIS: The Cowork/Code Linux sandbox likely needs the official Anthropic backend to provision/download its VM image. That path is broken when traffic is routed through CC Switch to DeepSeek — which would explain why it is permanently stuck on "Workspace still starting". The proxy/TUN-not-inheriting issue could be a secondary factor.

Could you please confirm:
1. Is the Linux sandbox supported at all when using CC Switch / a non-Anthropic provider like DeepSeek?
2. If I switch CC Switch back to "Claude Desktop Official", will the sandbox work? (I can test this if I have a usable Anthropic account.)
3. Does the sandbox/WSL2 environment inherit the host's system proxy (FlClash)? If not, how should I configure proxy for the sandbox so it can download its VM image?
4. Where is the sandbox VM image / cache stored on Windows, so I can delete it and force a re-download?
5. Where are the sandbox logs located, so I can see which step it is stuck on (image download / VM boot / networking)?

Environment: Windows 11 build 26200.x · Virtualization enabled (Task Manager) · WSL2 + VirtualMachinePlatform enabled via DISM (both returned success) · FlClash proxy with system proxy ON (rule mode, US exit node).

Start by reproducing the failure in the Cowork or Code tab on Windows 11, using the reported `echo hello` or `sleep 1` command and the listed WSL2 and VirtualMachinePlatform checks. Compare behavior with the third-party CC Switch gateway and the official backend if available, then inspect the sandbox startup path and logs. Done means the Linux workspace leaves the starting state within 10–30 seconds and bash commands execute normally.

Vom Indexierungsmodell aus dem Issue-Text verfasst.