Sidebar webview fails to render (gray/spinner): all vscode-resource asset requests fail with net::ERR_FAILED, no service worker registered

What version of the IDE extension are you using?

openai.chatgpt v26.707.41301 (stable channel; bundles codex CLI v0.144.0-alpha.4)

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

VS Code 1.127.0 (Electron 42.2.0, Chrome 148.0.7778.97)

What platform is your computer?

Linux 6.17.0-35-generic x86_64 x86_64 (Ubuntu 24.04.4 LTS, VS Code installed via .deb, not snap)

What issue are you seeing?

The Codex sidebar webview (chatgpt.sidebarSecondaryView) intermittently fails to render. It shows either a permanent gray/blank panel or a centered loading spinner that never resolves.

Opening the webview's own DevTools console/network shows every static asset request for the webview bundle failing:

GET https://file+.vscode-resource.vscode-cdn.net/home/<user>/.vscode/extensions/openai.chatgpt-26.707.41301-linux-x64/webview/assets/<name>-<hash>.js
net::ERR_FAILED

• 650+ requests, 100% failure rate, 0 B transferred, no response headers at all
• Uncaught (in promise) NetworkError: Failed to execute 'put' on 'Cache': Cache.put() encountered a network error thrown from service-worker.js
• DevTools → Application → Service Workers shows no registered service worker for the webview's origin when the panel is broken

Separately (possibly unrelated), a batch of malformed favicon requests also appears in the console, suggesting a string-truncation bug elsewhere in the webview:

GET https://status/favicon.ico net::ERR_NAME_NOT_RESOLVED
GET https://status.open/favicon.ico net::ERR_NAME_NOT_RESOLVED
GET https://status.openai/favicon.ico net::ERR_NAME_NOT_RESOLVED

(these look like incremental substrings of status.openai.com, as if a domain string is being sliced character-by-character before the favicon fetch)

Also hit once, unrelated to the webview bug but noting for context: right after first login, sending a message failed with unexpected status 404 Not Found: Model not found gpt-5.6-luna even though gpt-5.6-luna is listed in ~/.codex/models_cache.json with visibility: "list" and no upgrade/availability_nux gating. Switching to gpt-5.6-terra in ~/.codex/config.toml avoided that specific error.

What steps can reproduce the bug?

1. Fresh login via codex login (manual OAuth URL, since --device-auth requires enabling a "device code" security setting in ChatGPT first) — after login the webview worked once.
2. Fully quit and relaunch VS Code. Open the Codex sidebar. Sometimes it renders correctly; sometimes it shows gray/spinner with the asset-loading failure above.
3. Once broken, running the command Reload Webview on the Codex view basically never recovers it (tried 10 times in a row, 0 successes) — every reload creates a new vscode-webview://<random-id> origin and the asset requests fail again immediately.
4. Once it happens to work after a fresh full VS Code launch, reloading that same webview via Reload Webview reliably breaks it again immediately.
5. None of the following fixed it: Developer: Reload Window, full VS Code quit+relaunch (repeatable, ~coin-flip odds), clearing ~/.config/Code/{Service Worker,Cache,CachedData,Code Cache,GPUCache}, clearing ~/.config/Code/{Local Storage,Session Storage,blob_storage,WebStorage}, uninstalling+reinstalling the extension (code --uninstall-extension / code --install-extension, same version re-downloaded).
6. Ruled out as unrelated: other webviews in the same window (e.g. built-in Markdown Preview) always render fine, so this isn't a general VS Code webview/network-service problem. No proxy/DNS/hosts config is in play. AppArmor is unconfined for this VS Code install, no sandbox denials in dmesg/journalctl. The actual asset files exist on disk at the exact failing paths with correct size/permissions, and disk isn't full.
7. Backend health was independently confirmed throughout: the bundled codex app-server process authenticates and talks to chatgpt.com/ab.chatgpt.com without errors (checked via ~/.codex/logs_2.sqlite), and the standalone terminal CLI (.../bin/linux-x86_64/codex) works reliably even while the webview is broken.

What is the expected behavior?

The Codex sidebar should render the chat UI consistently across reloads/restarts, not intermittently depending on whether the webview's freshly-generated origin happens to get its service worker registered before the page's own bundle requests fire.

Additional information

Working theory (not confirmed inside VS Code's embedded DevTools since chrome://serviceworker-internals-style pages aren't reachable there): each Reload Webview mints a brand-new vscode-webview://<random> origin, and per the Service Worker spec, a page's own initial resource requests are never intercepted by a service worker that same page is in the middle of registering. If the webview's bootstrap doesn't wait for navigator.serviceWorker.ready before requesting its own JS/CSS bundle (i.e. no register-then-navigate pattern), then every fresh origin should deterministically fail on first paint unless a prior, already-activated registration happens to be reused — which would explain why a full app relaunch occasionally succeeds (reusing on-disk SW state) while an in-session Reload Webview essentially never does.

Workaround in the meantime: use the terminal CLI directly instead of the sidebar webview.