ntermittent dead renderer-to-extension-host RPC on load: restored workbench state (browser storage) races the web-worker exthost handshake; incognito always healthy #8051

Is there an existing issue for this?

• I have searched the existing issues

OS/Web Information

• Web Browser: Microsoft Edge (Chromium) on Windows 11 x64
• Local OS: Windows 11 x64
• Remote OS: Linux (cloud VM)
• Remote Architecture: x86_64
• code-server --version: 4.140.0

Steps to Reproduce

1. Use a long-lived normal browser profile that has accumulated site data for the code-server origin (approx 4 MB IndexedDB, actively rewritten during use).
2. Open or reload http://HOST:10029/?folder=WORKSPACE.
3. Wait 30-45 s for the workbench to boot.
4. Broken load: explorer tree and previously open editors are restored, but opening any file fails with "Cannot open editor because the file cannot be found"; no extension activates (clangd stops at creating its output channel).
5. Reload: the next load rolls again and may be healthy; a healthy load then stays healthy.
6. Open the same URL in incognito (no stored site data): first load is healthy and stays healthy.
7. Server-side during a broken load: exthost process alive and streaming, eager=0; during a healthy load eager=1. Same server, same minute.

Expected

Every page load establishes a working renderer-to-extension-host RPC channel: restored editors open their files and all extensions activate, regardless of how much session state the browser profile holds.

Actual

On most loads in a state-rich profile the renderer never answers exthost-initiated RPC for the whole session: extensions hang at activation step 1 and restored editors fail with file-not-found, while the explorer tree (restored from cache) is populated. Loads in incognito/fresh profiles are consistently healthy. Per-load outcome is independent (a race), not persistent corruption.

Logs

Browser console (broken load):
[WARNING] The web worker extension host is started in a same-origin iframe!
[INFO] Creating a socket (renderer-ExtensionHost-...) was successful after 190 ms.
[INFO] [AgentHost:remote] Connected; clientId=...
[INFO] [RemoteAgentHost] Reconciling: desired=[], current=[]
[ERROR] (empty message)   x3

Server side: exthost alive, bidirectional traffic flowing, renderer never replies;
eager=0 (broken) vs eager=1 (healthy).

Statistics, normal profile, single client: 5 loads -> 4 broken
(20:22, 20:25:27, 20:33, 20:42) / 1 healthy (20:25:13);
historical single-connection sessions 31 broken vs 13 healthy;
incognito first load healthy.

Client storage: origin IndexedDB approx 4 MB, log file rewritten during use;
clearing site data produced a healthy run.

Screenshot/Video

No response

Does this bug reproduce in native VS Code?

I did not test native VS Code

Does this bug reproduce in VS Code web?

I did not test VS Code web

Does this bug reproduce in GitHub Codespaces?

I did not test GitHub Codespaces

Are you accessing code-server over a secure context?

• I am using a secure context.

Notes

Hypothesis: at boot the workbench (a) wires the message channel to the web-worker extension host (same-origin iframe) and (b) replays restored session state from browser storage; these are not ordered. With a thick restore payload the restore path issues exthost-dependent requests before the renderer reply path is ready and the handshake/reply wiring is lost for that load; the exthost keeps sending RPC nobody answers (eager=0). Without restore state (incognito, fresh profile, after Clear site data) boot does essentially only the handshake and wins consistently.

Workarounds that change the odds: clear site data for the origin (after saving files); close all editors (Ctrl+K W) before closing/reloading; dedicated lightweight browser profile; wait 30-45 s before judging a reload (fast reloads kill healthy exthosts, observed a host killed at ~11 s).

Related: #4212 and #7914 (workbench state in browser storage; v4.141.0 adds opt-in --enable-remote-storage). Question: does enabling it remove this trigger, and does it cover extension-owned browser storage (language-server caches, dirty-file backups) as well? Also #7384 (restore triggers unexpected reloads, closed not_planned) and #7391 / #3140 (extensions unusable / unable to activate) look like downstream symptoms.

Requested: order/queue restore-path requests until the reply channel is ready (or retry), and make handshake failure detectable and self-healing instead of a silently dead channel.

Caveat: not tested in native VS Code, vscode web or Codespaces; the three dropdowns are set to "No" meaning observed only in code-server.

Happy to provide paired healthy/broken client console logs and server exthost logs with eager values and timelines.