VS Code extension cannot reopen some local sessions that CLI can resume

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #20094
• #18931
• #20029
• #20006

Powered by Codex Action

Thanks. The closest duplicates seem to be #18931 / #20094, but this report has a few differences that may help isolate the bug.

In my case:

• This happens in the official VS Code extension on VS Code Remote Linux, not Cursor/Antigravity on Windows.
• The affected JSONL session file is still valid and parseable.
• Codex CLI can resume the exact same session successfully.
• The failure is specific to the VS Code extension UI/hydration path.
• Clicking the affected session opens a blank page with no loading/error state.
• The model indicator falls back to custom/5.4, while the persisted turn context says gpt-5.5 medium.
• Reinstalling/restarting the extension does not make the affected session open again.

So this may share the same root cause as long-thread blank panel issues, but I think this issue adds Linux VS Code Remote evidence plus CLI-vs-extension isolation.

I’m seeing what looks like a regression in the Codex VS Code extension when opening older Task History sessions.

Environment:

• VS Code Remote WSL / WSL2
• Codex state path: ~/.codex
• Sessions are stored under ~/.codex/sessions
• Recent sessions created less than ~1 week ago load correctly
• Older sessions created ~1–2 months ago appear in Task History but open blank; after that, asking Codex anything causes the extension to lock up

Diagnostics:

• ~/.codex/session_index.jsonl exists and is valid JSONL
• The affected session files exist under ~/.codex/sessions/2026/...
• The affected session JSONL files parse cleanly line-by-line
• Moving aside/recreating state_5.sqlite and logs_2.sqlite did not fix the issue
• Rolling back the VS Code extension by two versions made the 2-month-old session load correctly again.

This suggests a recent extension/app-server regression loading older session/history formats, rather than local session corruption.

To summarize: older sessions load fine with version 26.422.30944 of the VS Code extension, but fail with 26.422.62136 and 26.422.71525.

Additional regression:
The VSCode Codex extension no longer shows usage information. I now have to open the web analytics page directly:
https://chatgpt.com/codex/cloud/settings/analytics#usage

This used to be visible in the extension until a few days ago.

Thanks. The closest duplicates seem to be #18931 / #20094, but this report has a few differences that may help isolate the bug. In my case: This happens in the official VS Code extension on VS Code Remote Linux, not Cursor/Antigravity on Windows. The affected JSONL session file is still valid and parseable. Codex CLI can resume the exact same session successfully. The failure is specific to the VS Code extension UI/hydration path. Clicking the affected session opens a blank page with no loading/error state. The model indicator falls back to custom/5.4, while the persisted turn context says gpt-5.5 medium. * Reinstalling/restarting the extension does not make the affected session open again. So this may share the same root cause as long-thread blank panel issues, but I think this issue adds Linux VS Code Remote evidence plus CLI-vs-extension isolation.

I am experiencing the same issue under the exact same setup as you with VS Code Remote on Linux.

Additional regression: The VSCode Codex extension no longer shows usage information. I now have to open the web analytics page directly: https://chatgpt.com/codex/cloud/settings/analytics#usage This used to be visible in the extension until a few days ago.

same here. The usage view/function seems to work though for some older versions of the codex extension such as 26.5417.40842 for example

Reproduced again on the latest stable VS Code extension build.

Environment

• Codex VS Code extension: openai.chatgpt 26.715.61943 (linux-x64)
• Bundled CLI: codex-cli 0.145.0-alpha.27
• VS Code: 1.129.1
• OS: Ubuntu 24.04 guest running in VMware
• Desktop session: Wayland (GDK_BACKEND=x11)
• Renderer: VMware SVGA3D / Mesa 25.2.8; glxinfo -B reports Accelerated: no

The extension was installed at 2026-07-22 09:09 CST. Marketplace metadata reports this stable build was published at 2026-07-21T20:22:52Z.

Behavior

Codex views can become blank or remain unable to load, especially around older/longer local sessions. The app-server itself starts and remains active, so this does not look like a CLI startup failure.

Two affected session/log combinations observed locally:

• Thread 019f8513-b2f7-7a80-afef-9bd43bccd31b
• JSONL size: 6,151,829 bytes
• ResizeObserver loop completed with undelivered notifications: 1,079 occurrences
• Thread 019f4ada-5147-79d3-9c62-d53192831313
• JSONL size: 13,592,748 bytes
• Same ResizeObserver error: 630 occurrences

The local session store currently contains 210 JSONL sessions totaling about 601 MB; 15 sessions are larger than 10 MB. This suggests that individual long-thread hydration/rendering, and possibly the size of the local history index, are important triggers.

Relevant startup evidence

The extension log shows successful initialization before the UI failure:

Activating Codex extension
[CodexMcpConnection] Spawning codex app-server
[CodexMcpConnection] Initialize received id=1
[startup][renderer] app routes mounted after 3420ms

After rendering begins, the log repeatedly emits:

[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.

There is also a repeatable remote settings failure:

Error fetching httpStatus=403 statusText=Forbidden url=/settings/user

The /settings/user 403 may be a secondary issue related to the blank Settings view, but it is not a network timeout: the server returns an explicit response.

I did not find any of the signatures seen in the earlier GPU/resource-loading failure:

• no GPU process crash
• no net::ERR_FAILED
• no CSP/preload failure
• no JavaScript SyntaxError
• no WebView resource load failure

Historically, launching VS Code with --ozone-platform=x11 made the Settings view render on this VMware/Linux setup, but that is only a compositor workaround and does not address the repeated ResizeObserver/hydration failure.

Expected behavior

• Long local sessions should be paginated or virtualized rather than making the WebView blank/unresponsive.
• A session that cannot be hydrated should show a recoverable error instead of an empty panel.
• A 403 from /settings/user should not prevent the local Settings shell from rendering.
• Rendering should not produce hundreds or thousands of ResizeObserver loop errors.

No session contents, credentials, repository names, or account data are included in this report.

Another reproducible case with a large local session

I am seeing the same failure in the official Codex VS Code extension on a remote Linux machine.

Environment

• VS Code Server: 1.129.1
• Codex extension: openai.chatgpt 26.715.31925 (linux-x64)
• Bundled CLI: codex-cli 0.145.0-alpha.18
• Remote host: Linux x86-64
• Clients tested:
• VS Code desktop on macOS Apple Silicon
• vscode.dev in Chrome

Behavior

The extension starts normally, the app-server initializes, and the chat list appears. Smaller sessions open without a problem.

For one older and much larger session, the transcript appears briefly and then the view crashes with:

Oops, an error has occurred

In some attempts the Codex panel becomes blank or the VS Code window stops responding. The same session fails in both desktop VS Code and vscode.dev, so this does not appear to be limited to the local Electron renderer or GPU configuration.

What I checked

The affected session is still valid and readable outside the IDE:

• every JSONL record parses successfully;
• SQLite quick_check and integrity_check both pass;
• thread/read succeeds;
• paginated turn reads succeed;
• the app-server reaches maybe_resume_success;
• the exact same session can be resumed with codex resume <thread-id>.

The session is large:

rollout size: about 285 MB
turns: 168
display items: 18,001
largest JSONL record: about 2.5 MB

The extension log repeatedly contains:

ResizeObserver loop completed with undelivered notifications.

I also tested a fork ending much earlier in the same history. The short fork renders correctly, while the complete session still crashes. This makes a long-thread hydration or layout problem more likely than corrupted persisted data.

There are also repeated background warnings such as:

Error fetching ... 403 ... /settings/user

and unknown internal feature keys, but authenticated account/model/plugin calls still succeed. These warnings seem secondary to the rendering failure.

Current workaround

The original session remains usable through the CLI. In the IDE, the only practical workarounds are:

• continue the original session with codex resume <thread-id>;
• fork from an earlier point;
• start a new chat and carry over a handoff summary.

Expected behavior

Large sessions should be loaded incrementally or virtualized instead of rendering the entire history at once. Large tool outputs, images, base64 payloads, and older turns could be collapsed or loaded on demand.

At minimum, when a session cannot be rendered, the extension should show a recoverable error with options such as:

• load only the latest turns;
• open the session in the CLI;
• fork before the failing turn;
• export a diagnostic bundle.

A session that the app-server can read and resume should not make the whole conversation view blank or unresponsive.

Additional current reproduction: the issue is still present in a newer stable VS Code extension build.

Environment

• VS Code Remote on Linux x86-64
• Codex extension: openai.chatgpt 26.721.41059 (linux-x64)
• System CLI used by the extension: codex-cli 0.145.0
• Affected thread was originally created with CLI 0.142.4
• Thread history mode: legacy

Behavior

Opening one specific older local thread from its correct, existing workspace shows the localized equivalent of:

Oops, an error has occurred
Try again

The exact same thread remains usable with codex resume <thread-id>.

Persistence and app-server validation

All identifiers, paths, hostnames, project names, and message content are omitted here.

• state_5.sqlite: PRAGMA quick_check returns ok
• The thread row exists, is not archived, and points to an existing rollout
• session_index.jsonl contains the thread and parses successfully
• Rollout: approximately 43.3 MB, 21,188 valid JSONL records
• Largest JSONL record: approximately 136 KB
• thread/read succeeds with both includeTurns: false and includeTurns: true
• Full reconstruction returns 156 turns: 153 completed, 3 interrupted
• Reconstructed history includes 29 contextCompaction items
• The last reconstructed turn is completed
• Approximately 2,649 display items are reconstructed
• No database or rollout repair was required

Extension log boundary

The failure is immediate and occurs before the extension starts resuming the thread:

thread_stream_view_activity_changed active=true  resumeState=needs_resume streamRole=null
thread_stream_view_activity_changed active=false resumeState=needs_resume streamRole=null
error boundary ... error={} name=AppRoutes

The first AppRoutes error follows the activity change within roughly 50 ms. Retrying produces the same AppRoutes error. There is no maybe_resume_started, maybe_resume_success, or thread-resume RPC for the affected thread before the UI error.

In another VS Code window, a much larger local thread reaches maybe_resume_success through the same app-server/runtime. This isolates the failure to the extension's route/hydration/rendering path for this particular reconstructed history rather than general authentication, CLI startup, or database access.

I also verified all 567 dynamic JavaScript import targets referenced by the installed WebView assets: none are missing.

Secondary observations

• /settings/user returns 403, but other local threads still work, so this appears secondary.
• With multiple VS Code windows open, one extension host logged Codex IPC socket is not owned by the current user while several extension hosts were contending for the shared Codex IPC socket. The socket ownership and mode were subsequently correct, broadcasts were received afterward, and the AppRoutes failure still repeated. This looks like a separate multi-window race rather than the primary cause here.

Diagnostic gap

The error-boundary log serializes the exception as error={} while retaining only the component stack. Preserving at least the exception name/message in the extension log would make this class of failure much easier to isolate.

This reproduction supports a frontend lazy-route/hydration/rendering regression for valid legacy histories, not local session corruption or an incorrect workspace path.

Thread-ID 019f157b-5c2e-7592-92a9-b43817c37de7

Your 401-line session is a useful control case: every JSONL line parses, CLI resume succeeds, but the VS Code extension permanently renders a blank page and even falls back to the wrong model label.

I’m testing whether Codex Rescue independently discovers and diagnoses sessions that are healthy on disk but unusable in one client. It will not modify the rollout or repair the extension’s hydration/rendering path; it should simply establish the local structural boundary safely.

If one affected session still exists, could you try:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized output is sufficient—please don’t share raw JSONL, SQLite data, prompts, private paths, repository contents, or secrets.

https://github.com/shleder/codex-rescue