[BUG] VS Code (Remote-WSL): clicking a tool block times out after 1000ms (open_content) and freezes the Claude panel

Summary

In the VS Code extension over Remote-WSL, clicking a tool block (e.g. a Bash command/output) in the Claude panel to open its content almost always fails. The extension waits only 1000 ms for the new tab to appear, the request errors, and the webview doesn't handle the error. The panel then stops responding (it looks frozen) until the webviews are reloaded.

Environment

• Claude Code VS Code extension 2.1.283 (also seen on 2.1.280)
• VS Code on Windows, workspace opened via Remote-WSL (WSL2)
• permissionMode: bypassPermissions, Remote Control enabled

Steps to reproduce

1. Open a workspace in WSL via Remote-WSL and start a Claude session in the panel.
2. While Claude is working (streaming), click a Bash tool block (the IN/OUT box) in the panel to open its content in an editor tab.

Actual

Extension log (Claude VSCode.log):

18:51:36.055 Received message from webview: {"type":"request","requestId":"b3c5vucmjnq","request":{"type":"open_content","content":"..."}}
18:51:37.210 [error] Error processing client request: Error: Timeout waiting after 1000ms
18:51:37.256 Received message from webview: {"type":"interrupt_claude","channelId":"b3c5vucmjnq"}
18:51:37.257 [warning] Channel not found: b3c5vucmjnq

Webview DevTools console:

Uncaught (in promise) Error: Timeout waiting after 1000ms
    at readMessages (webview/index.js:1440)

Afterwards the panel stops responding. It recovers after "Developer: Reload Webviews" or reopening the tab.

On one machine in one day, 13 of 14 open_content requests failed this way, across several windows.

Root cause (from the bundled extension.js)

In the function that handles open_content (minified xb$), after showTextDocument the extension waits for a tab with the generated label and gives up after 1 s:

let U = await JK(() => { return $K().find((Z) => Z.label === V) }, 1000);

Over Remote-WSL the readonly temp-file provider round trip means the tab often takes longer than 1 s to show up in window.tabGroups (especially while a response is streaming). The rejection propagates to the webview as an error response.

In the webview, an error response triggers interruptClaude(requestId), which passes the requestId where a channelId is expected (hence Channel not found), and the rejected promise is unhandled.

Suggested fix

• Make the tab lookup in open_content non-fatal and/or use a much longer timeout, e.g. JK(..., 10000).catch(() => undefined). KY() already handles an undefined tab.
• In the webview, don't call interruptClaude() for a failed open_content request (and not with a requestId), and handle the rejection.

Workaround

Patching the line above locally to JK(..., 10000).catch(() => void 0) and restarting the extension host avoids the failure.