[BUG] Voice mode aborts immediately on Linux (Bun ws unexpected-response event not implemented)

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?

Environment

• Claude Code: 2.1.126.507
• Install: npm-global (Bun-compiled binary, /$bunfs/root/src/entrypoints/cli.js)
• OS: Linux 6.6.87.2-microsoft-standard-WSL2 (Ubuntu on WSL2)
• Audio: PulseAudio via WSLg (pactl info reports server OK; RDPSource mic present); arecord -D pulse works fine

outside Claude Code.

Steps to reproduce

1. /voice → tap mode enabled
2. With input empty, tap the bound key (ctrl+w) once
3. Recording session opens and aborts ~15 ms later, before any audio is captured

Expected: Recording stays open until the second tap.

Actual: Recording auto-finishes immediately. Final transcript is "". WebSocket then connects ~600 ms later and is
closed with code 1000 because the session is already gone.

Debug log excerpt (timestamps trimmed)

[voice] toggle: starting recording
[voice] startRecording called, platform=linux
[voice_stream] Connecting to wss://api.anthropic.com/api/ws/speech_to_text/voice_stream?...
[ERROR] Error: console.error: [bun] Warning: ws.WebSocket 'unexpected-response' event is not implemented in bun
at K (/$bunfs/root/src/entrypoints/cli.js:545:12024)
at emitWarning (ws:43:42)
at #onOrOnce (ws:170:18)
at EO8 (/$bunfs/root/src/entrypoints/cli.js:7603:4503)
[voice] finishRecording: stopping recording, transitioning to processing
[voice] Recording stopped
[voice] Final transcript assembled (0 chars): ""
[voice_stream] WebSocket connected
[voice_stream] WebSocket closed: code=1000 reason=""

Reproduces deterministically on every tap.

Likely root cause

The voice client registers a handler for the ws library's unexpected-response event. Bun's ws shim doesn't implement
that event, so it emits a console.error warning during WebSocket handshake. The voice flow appears to treat that
warning as a fatal error and calls finishRecording before the WebSocket has finished connecting — which is why the WS
is then closed cleanly (1000) immediately after connecting, with zero audio sent.

Suggested fix directions

• Don't treat the unexpected-response-not-implemented warning as fatal in the voice path, or
• Switch the voice WebSocket to a connection method that doesn't depend on the unexpected-response event under Bun, or
• Upstream: add unexpected-response to Bun's ws shim.

Workaround: none on the user side — audio stack and keybinding are not involved.

What Should Happen?

Voice mode is working under this specific installation

Error Messages/Logs

Steps to Reproduce

Likely root cause

The voice client registers a handler for the ws library's unexpected-response event. Bun's ws shim doesn't implement
that event, so it emits a console.error warning during WebSocket handshake. The voice flow appears to treat that
warning as a fatal error and calls finishRecording before the WebSocket has finished connecting — which is why the WS
is then closed cleanly (1000) immediately after connecting, with zero audio sent.

Suggested fix directions

• Don't treat the unexpected-response-not-implemented warning as fatal in the voice path, or
• Switch the voice WebSocket to a connection method that doesn't depend on the unexpected-response event under Bun, or
• Upstream: add unexpected-response to Bun's ws shim.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.126.507

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_