Codex panel webview retry-floods failed asset requests in code-server, exhausting and crashing the shared render process (freezes every tab)

Environment

• Extension: openai.chatgpt 26.5707.31428 and 26.5707.41301 (both reproduce), installed via VSIX
• Host: code-server 1.127.0 (VS Code web), Linux x64 container, HTTPS behind reverse proxy
• Browser: Brave 150.1.92.139 (Chromium 150) on Pop!_OS Linux (kernel 7.0.11-76070011, x86_64, Wayland)
• Panel set to auto-open (restored layout) in every window

Summary

When code-server's webview service worker fails to intercept resource loads (an intermittent, race-like condition on the host side — companion report filed against coder/code-server), the Codex panel's webview assets fail with net::ERR_NAME_NOT_RESOLVED against vscode-cdn.net — and the extension retries in an unbounded tight loop. The retry flood exhausts Chromium's per-render-process pending-request pool (FetchEvent ... insufficient resources for all requests in the process), then crashes the renderer ("Render process gone"). Because same-site tabs share the render process, every open code-server tab freezes at once.

Reproduction (deterministic in our environment)

Codex panel auto-opening per window + ~6 concurrent same-site code-server tabs → renderer crash on the 6th. Also: enabling the extension in a live window froze all tabs instantly; with the extension disabled the same workload is stable indefinitely (A/B verified both directions).

Why we're reporting to you as well as code-server

The interception failure looks host-side, but the extension's unbounded retry behavior converts a cosmetic asset failure into a renderer-killing flood, and the auto-open-in-every-window panel multiplies exposure. A retry cap / backoff on webview asset loading would contain the blast radius regardless of the host bug. (#17357 documents a similar unbounded-retry pattern in this extension against unsupported host endpoints — same missing-backoff class.)

Evidence available

Console captures of the ERR_NAME_NOT_RESOLVED + insufficient-resources storms, growing loadResource listener leak (175→615+), healthy-baseline HARs for contrast, "Render process gone" screenshot, a deterministic repro recipe, and a browser-process netlog spanning a deterministic crash: real DNS queries for main.vscode-cdn.net failing at the crash moment (and recurring from the dead tab afterward), with no network-service-level flood — confirming the exhaustion happens inside the renderer's fetch/SW layer. Happy to attach any of these.