Extension host crashes with "callback not provided" when DISPLAY forwarding target is unreachable

Extension host crashes with "callback not provided" when DISPLAY forwarding target is unreachable

claude-authored, user-supervised report.

but experienced and "fixed" with changing

{ if (e) throw xne(e, "callback not provided") }

to

 { if (e) console.error("muxrpc unhandled:", e) }.

in the bundled extension.js

My problem was that whenever I ran octave-cli from within the devcontainer, vs code appeared to die. A subsequent reload would fix it, but very annoying.

---

VS Code: 1.116.0 (system setup), commit 560a9dba96f961efea7b1612916f89e5d5d4d679
Dev Containers: 0.454.0
Local OS: Windows 11 (10.0.26100) + WSL2, Docker Desktop
Remote: Linux devcontainer

Repro

1. In WSL, export DISPLAY=<windows-host-ip>:0 with no X server listening (common VcXsrv/X410 setup when the X server isn't running).
2. Open a folder in a devcontainer. Inside the container, echo $DISPLAY shows :0 (or :1, :2, … — the number sometimes increments). Dev Containers has set up its own X11 forwarding tunnel from this local display number back to the WSL host IP.
3. Run any program that opens an X11 connection at startup — octave-cli reproduces reliably.
4. The X11 client connects to the Unix socket for the local display, Dev Containers' tunnel forwards it to <windows-host-ip>:6000, nothing is listening there → ECONNREFUSED.
5. Extension host crashes; VS Code shows "Reconnecting to Dev Container".

The target process itself stays alive inside the container — only the VS Code extension host dies. A window reload reconnects and the program is running normally at its prompt.

Console output

[ms-vscode-remote.remote-containers] callback not provided
Error: callback not provided
    at bne (…/remote-containers-0.454.0/dist/extension/extension.js:15:1730)
    …
    at Pipe.onStreamRead (node:internal/stream_base_commons:189:23)

  Error: connect ECONNREFUSED 10.255.255.254:6000
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16)

INFO Extension host (Remote) is unresponsive.

Root cause

The bundled muxrpc library defaults to a throwing callback when an RPC method is invoked without one:

function bne(e) { if (e) throw xne(e, "callback not provided") }

When Dev Containers' X11 forwarding socket gets ECONNREFUSED on the outbound connection to the WSL host, the error reaches this default callback, which throws synchronously from a socket read handler. Nothing catches it; the extension host dies.

Fix should live in Dev Containers' use of muxrpc — the X11 forwarding RPC call needs a real callback (or the muxrpc client should be wrapped with a non-throwing fallback) so socket errors have somewhere to go instead of crashing the host.

Workaround

"remoteEnv": { "DISPLAY": "" } in devcontainer.json disables the forwarding and avoids the crash. Patching bne locally to console.error instead of throwing also confirms the diagnosis — the extension host survives, and the X11 connection fails cleanly as expected.

Related

#7983 — Dev Containers assigns incrementing DISPLAY numbers. Same forwarding code path; this issue is what happens when the upstream target is unreachable.