Panel stuck on the logo after an in-place extension update: stale VS Code webview service-worker cache (root cause + workaround; likely explains #15975 / #28280 / #32388)

Summary

This is a VS Code platform bug, but Codex can and should defend against it — and<br>right now it is silently eating a whole cluster of your "blank panel / stuck on<br>logo" reports.

I was able to nail down the root cause on the Codex extension, so I am reporting it<br>here as well as upstream:

After openai.chatgpt updates in place, VS Code's on-disk webview<br>service-worker cache keeps resolving webview/assets/*.js against the previous<br>extension directory — which VS Code itself deletes on the next start. Every chunk<br>fails with net::ERR_FAILED, the React app never mounts, and the panel shows<br>nothing but the OpenAI logo. Because the cache lives on disk, this survives a panel<br>reload, a window reload, a VS Code restart and a full machine reboot.

Upstream report (root cause, full evidence): [https://github.com/microsoft/vscode/issues/325767](<https://github.com/microsoft/vscode/issues/325767>)

I only have a workaround, not a fix — see below. But the mitigation I am asking<br>for here is cheap and lives entirely on your side.

Why this is your problem too

The fix belongs to VS Code, but the last time this exact mechanism was reported<br>against an extension (anthropics/claude-code#13130 — same bug, different vendor) it<br>was closed as not planned and nothing happened. Meanwhile these are all still open<br>in this tracker, all with the same symptom and no root cause found:

• openai/codex#32388 — Linux, VS Code 1.128.0, extension 26.707.41301: that is the<br>exact VS Code + extension version pair I reproduced this on. The reporter's<br>accidental workaround (code --disable-extension <anything>) is consistent with a<br>cache/startup-state artifact rather than an extension conflict.
• openai/codex#15975 — "stuck on loading/logo screen after VS Code update", no maintainer response.
• openai/codex#28280 — "Codex panel empty in VS Code".

I would bet a good share of these are one bug.

What I ask for

1. Force a window reload after an in-place update. The extension knows its own<br>version. If the running version differs from the version the webview was built<br>against, prompt for (or force) Reload Window rather than rendering into a resource<br>map that can no longer resolve. This alone would make the panel immune, regardless of<br>what VS Code does.
2. Version-stamp the webview asset URLs. If the asset URLs carried the extension<br>version, a stale service-worker entry could not silently shadow the new build.
3. Detect and surface it. If the webview's asset fetches fail, say so in the panel<br>("the extension was updated — reload the window") instead of showing a logo forever.<br>The current failure mode is undiagnosable for a normal user: every log is green.

Evidence

Environment: Debian 12 (bookworm), kernel 6.1.0-50, x64 · VS Code 1.128.0<br>(fc3def6774c76082adf699d366f31a557ce5573f) · openai.chatgpt 26.707.71524<br>(previously 26.707.41301, before that 26.707.31428) · ChatGPT sign-in,<br>codex login status green throughout.

1. VS Code deletes the old extension dir the cache still points at —<br>~/.config/Code/logs/20260714T120150/sharedprocess.log:

2026-07-14 12:01:55.024 [info] Marked extension as removed openai.chatgpt-26.707.41301-linux-x64
2026-07-14 12:01:56.557 [info] Deleted marked for removal extension from disk openai.chatgpt /home/tg/.vscode/extensions/openai.chatgpt-26.707.41301-linux-x64

Only the new directory remains, and there is no stale openai.chatgpt entry in<br>.obsolete — so this is not the "old folders left behind" theory from<br>anthropics/claude-code#13130. Cleanup is clean; the cache is simply never told.

2. The cache predates the new extension. mtimes in the broken state:

2026-07-14 09:45:41  ~/.vscode/extensions/openai.chatgpt-26.707.71524-linux-x64  <- new extension
2026-07-12 16:17:52  ~/.config/Code/Service Worker                               <- built while 41301 was live
2026-07-12 16:17:49  ~/.config/Code/{Cache,Code Cache,CachedData,GPUCache}

3. The Codex backend is completely healthy — it is purely the webview.<br>window1/exthost/openai.chatgpt/Codex.log from the broken session:

2026-07-14 12:01:54.428 [info] Activating Codex extension
2026-07-14 12:01:54.428 [info] [CodexMcpConnection] Spawning codex app-server
2026-07-14 12:01:56.106 [info] [CodexMcpConnection] Initialize received id=1

renderer.log and exthost.log: no errors at all. This is the trap. Everyone<br>debugging this — including me, the first time — goes after the app-server or the<br>auth, because that is where you would look. Both are fine. My id_token had been<br>expired for days and it was still irrelevant.

**4. The only place the error appears — Developer: Open Webview Developer Tools → Console:**

Failed to load resource: net::ERR_FAILED   .../webview/assets/<chunk>.js

…for chunks that exist on disk under the new extension path.

Full disclosure: that console capture is from the first occurrence (2026-07-12). On<br>the second (2026-07-14) I went straight to the fix and did not re-open DevTools; all<br>other evidence above is from 2026-07-14.

Workaround for anyone landing here

Delete VS Code's caches with VS Code shut down (pure caches — settings and<br>extensions are untouched, VS Code rebuilds them):

pkill -TERM -f '/usr/share/code/code'   # and wait for it to actually exit
rm -rf ~/.config/Code/{"Service Worker",Cache,"Code Cache",GPUCache,CachedData}
rm -rf /tmp/codex-ipc
code

2 / 2 successful. What does not work: reloading the panel, Reload Window,<br>restarting VS Code, rebooting, killing the app-server, re-authenticating.

Diagnosis shortcut, faster than opening DevTools: if<br>~/.vscode/extensions/openai.chatgpt-* is newer than<br>~/.config/Code/Service Worker, you have this bug.