Webview asset requests escape to vscode-cdn.net (real DNS) instead of being service-worker-intercepted; renderer-internal retry flood crashes the render process, freezing all same-site tabs

[oohhddaanngg]

Is there an existing issue for this?

• I have searched the existing issues (closest related: Dynamically webview resources fail to load in some browser/OS combinations #3410 — webview resources stuck pending in some browser/OS combos; overlapping symptom but no renderer-crash chain)

OS/Web Information

• Web Browser: Brave 150.1.92.139 (official build, Chromium 150, Wayland)
• Local OS: Pop!_OS Linux (kernel 7.0.11-76070011-generic, x86_64)
• Remote OS: Linux (Podman container, behind Caddy reverse proxy, HTTPS/wss)
• Remote Architecture: amd64
• code-server --version: 1.127.0 1e6ed87

Summary

Intermittently — apparently a race — webview resource requests are not intercepted by the webview service worker and instead go to the virtual hostname vscode-cdn.net (main.vscode-cdn.net at the network layer, vscode-resource.vscode-cdn.net in console captures) via real DNS, failing with net::ERR_NAME_NOT_RESOLVED. The failed requests retry in a tight loop inside the renderer, the shared render process's pending-request pool exhausts (FetchEvent ... resulted in a network error response: insufficient resources for all fetches), and the render process eventually crashes ("Render process gone" in DevTools). Because all same-site code-server tabs share that render process, every open tab freezes simultaneously.

The trigger extension in our setup is OpenAI Codex (openai.chatgpt, 26.5707.31428 and 26.5707.41301) — the heaviest webview here, auto-opening its panel in every window — but the interception failure appears to be host-side. We are filing a companion report against the extension for its unbounded retry behavior.

Steps to Reproduce

1. Codex extension enabled; its panel webview auto-opens per window.
2. Open ~6 concurrent tabs to the same code-server host in one Chromium profile (same-site → shared render process).
3. On the 6th tab: renderer dies; all tabs freeze. DevTools on any of them reports "Debugging connection was closed. Reason: Render process gone."

Also reproduces spontaneously with fewer long-lived tabs after hours (race-dependent), and enabling the extension in a live window has frozen all tabs instantly. With the extension disabled, the same workload is stable indefinitely (A/B verified both directions).

Expected

Webview asset requests are always served by the webview service worker / same-origin route; a webview-heavy extension cannot take down the shared render process for every tab.

Actual

Webview asset requests intermittently escape to vscode-cdn.net via real DNS and fail; the renderer-internal retry flood exhausts the process and crashes it, freezing all same-site tabs at once.

Evidence

• Browser-process netlog (chrome://net-export) spanning a deterministic crash (survives renderer death): real DNS lookups for main.vscode-cdn.net — a virtual hostname that should never reach DNS — failing ERR_NAME_NOT_RESOLVED at the crash moment and recurring from the zombie tab afterward; 6 webview pre/index.html spinups in ~30 s preceding the crash. Notably the netlog shows no network-service-level flood and zero ERR_INSUFFICIENT_RESOURCES — the exhaustion is renderer-internal (fetch/SW layer). Server logs during the same window are clean (connections establish, extension hosts launch) — the freeze is entirely client-side. Can share the netlog on request (will scrub cookies/headers).
• Frozen-tab console capture: storm of FetchEvent for <url> resulted in a network error response: insufficient resources (Chromium per-process pending-request cap; cf. Batching of precache requests to prevent net::ERR_INSUFFICIENT_RESOURCES in Chrome GoogleChrome/workbox#2528).
• Earlier capture during degradation: webview assets failing to vscode-resource.vscode-cdn.net with ERR_NAME_NOT_RESOLVED, and a loadResource listener count growing 175→615+.
• Healthy-baseline HAR for contrast: zero requests to vscode-cdn.net — webview SW intercepting normally (webview pre/index.html 200, assets served same-origin).
• DevTools screenshot of "Render process gone" at the moment of freeze.
• Operational note: restarting code-server to "fix" frozen tabs makes it worse — stranded tabs flood Unknown reconnection token (never seen) and the reconnect storm re-triggers the exhaustion. Recovery that works: close other same-site tabs first, then reload one.

Does this bug reproduce in native VS Code?

Not applicable — the failure path (browser webview service worker + shared same-site render process) only exists in web deployments; desktop VS Code doesn't use it.

Questions for maintainers

• Is there a known race where the webview SW loses registration/claim (or is evicted in long-lived tabs), letting resource requests fall through to the vscode-cdn.net default?
• Any recommended mitigation (SW re-registration, request retry cap) we can apply server-side?

[linear-code]

DEVEX-626

[oohhddaanngg]

Companion report against the triggering extension (unbounded retry behavior): openai/codex#32475