[Bug][0.2.1-rc.2] Inspector bundle injects a loopback-only endpoint (ws://127.0.0.1:9230/ingest); LAN/remote browsers get periodic mux disconnects

[chaos-03x]

Summary

When the optional @deepseek-ai/dsh-experimental-inspector-profile bundle is enabled — documented as "off by default in Plugin Manager" and switched on via Developer Tools — the Host injects this bootstrap into every Web page:

"__DSH_INSPECTOR__": {
  "endpoint": "ws://127.0.0.1:9230/ingest",
  "reconnectBaseMs": 250,
  "reconnectMaxMs": 5000
}

127.0.0.1 is hardcoded. For any browser that is not running on the Host machine (LAN, reverse proxy, SSH-tunnel / remote clients), it resolves to the client machine, where no DSH inspector is listening. The inspector client therefore never connects and retries every 0.25–5 s, filling the console with WebSocket connection to 'ws://127.0.0.1:9230/ingest' failed / 403 / 1006.

On those clients, /api/remote.mux is torn down periodically, the UI repeatedly shows a "connected" toast, and recovery takes tens of seconds.

Environment

• @deepseek-ai/dsh 0.2.1-rc.2, web profile
• Host: WSL2 (6.18.58.1-microsoft-standard-WSL2), dsh web bound to 127.0.0.1:3080 behind a LAN reverse proxy (192.168.10.x:8080)
• Client: macOS + Chrome; also reproduced in everyday browsers (all brands)
• The bundle entered dsh.profile.bundles when the profile was regenerated on upgrade; all package.json backups from 2026-10-05 to 2026-10-12 predate it
• Loopback access (127.0.0.1:3080 on the Host) is unaffected, as expected

Symptoms

• Periodic teardown of /api/remote.mux, with no WebSocket close frame (1006 / ECONNRESET)
• Console repeatedly shows [connection] connection lost, retry #1 and [connection] generation is still not ready after 3000ms
• 23–49 s from disconnect to reconnect in our captures, consistent with backoffBaseMs=500, factor=2, backoffMaxMs=10000
• Switching sessions triggers an immediate successful reconnect (the manual reconnect() aborts the backoff wait)
• Only non-loopback clients are affected

Relation to existing discussions

We searched Discussions first; several reports describe similar symptoms but different root causes:

• [求助] Web 面板约每 12 秒断连重连（"连接成功"反复弹出）——session/follow 大快照疑似触发服务器端销毁 mux 连接 #9603 — ~12 s reconnect loop with repeated "connected" toasts, traced to a 4.3 MB session/follow snapshot
• [Bug] WebSocket heartbeat defaults (2s interval + 2 missed) tear down connections on mobile / high-latency networks → ~12s reconnect loop #9797, Bug: mux heartbeat kills a healthy browser WebSocket (endless ~10s reconnect loop) #6092, gateway: 2s websocket heartbeat default disconnects relayed mobile clients (remote.mux / $events) #6867 — 2 s heartbeat plus 2 missed pongs terminating healthy connections
• dsh web: keepAliveTimeout (5 s default) still unfixed in 0.2.1-rc.2 — independent reproduction and verified fix #10533 — the 5 s keepAliveTimeout default (we applied that workaround independently; it reduced but did not eliminate our disconnects)
• [Bug] WebSocket 会话被服务端反复关闭，前端「新建会话」死锁（Windows 11 / iOS / Android 全部实测复现） #11471 — server-side WebSocket closes reproduced across Windows, iOS and Android
• [Bug] Desktop 0.2.1-rc.2: enabling the experimental "Developer tools" can crash the host after its inspector source closes — "inspector: Host source is closed" #10069 — enabling "Developer Tools" crashes the Host (inspector: Host source is closed), a different inspector failure mode
• [Bug] dsh-client-ui-chat causes renderer main-thread freeze on startup (Windows, 0.2.1-rc.3) #11283 — explicitly noticed ws://127.0.0.1:9230/ingest failing, but called it a red herring for a renderer freeze

To our knowledge nobody has linked this loopback-only inspector endpoint to periodic disconnects on non-loopback clients. It may also be worth re-checking on #9603-style setups.