›_ Codex Issues
Codex Issues / #22996

Codex Desktop: completed threads become inaccessible after update

Resolved 💬 7 comments Opened May 16, 2026 by wowfraga-eng Closed May 16, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex Desktop: completed threads become inaccessible after update

Summary

After updating Codex Desktop and signing in again, some completed chat threads become inaccessible from the sidebar. The UI shows a generic error:

Oops, something went wrong

This is not limited to old pre-update conversations. A new thread created after the update also became inaccessible immediately after a normal completed turn.

In an earlier affected thread, the UI exposed a more specific resume error showing a path-normalization mismatch between a normal Windows path and an extended-length Windows path:

cannot resume running thread ... with stale path: requested <normal Windows Codex session path>, active <extended-length Windows Codex session path>

The visible mismatch was essentially:

requested: C:\...
active:    \\?\C:\...

Environment

  • Product: Codex Desktop
  • OS: Windows
  • Codex Desktop version observed in logs: 26.513.31313
  • Codex CLI/runtime version for the new affected thread: 0.131.0-alpha.9
  • Auth mode: ChatGPT account
  • Local timezone: UTC+05:00

Affected Threads

New post-update thread

  • Thread id: 019e2fa8-bd2c-7911-bd70-ec40e63c98ad
  • Thread was created after the Codex Desktop update.
  • Rollout JSONL file exists in the local Codex sessions folder.
  • Rollout file size: about 5.4 MB.
  • Created: 2026-05-16 07:20:48 UTC
  • Last updated: 2026-05-16 09:10:53 UTC
  • Thread state:
  • parent rollout JSONL exists
  • parent rollout tail contains the final assistant answer
  • parent rollout tail contains task_complete
  • all 14 child subagent threads are marked closed
  • the Git commit created during the turn exists
  • project working tree was clean after the commit

Last commit created by the affected thread:

a9d3c42 Fix profile-scoped settings and sources

Checks reported by the completed thread before it became inaccessible:

ruff check autobrief tests -- passed
pytest -- 353 passed
git diff --check -- no errors, only standard CRLF warnings
git status --short --ignored=no -- clean after commit

Older affected thread with explicit stale-path error

  • Thread id: 019e27a1-3c0e-7d61-ab57-9b3360b3c3ad
  • Earlier CLI/runtime version: 0.130.0-alpha.5
  • The resume error reported a path-normalization mismatch between normal Windows paths and extended-length Windows paths:
requested: C:\...
active:    \\?\C:\...

Reproduction Pattern

  1. Update Codex Desktop.
  2. Fully exit Codex Desktop and sign in again.
  3. Open or create a thread in a Windows project workspace.
  4. Work normally in the thread. In the new post-update case, the thread used subagents/Critic, completed code changes, created a Git commit, and returned a final answer.
  5. The rollout JSONL records a normal final answer and task_complete.
  6. Return to the thread from the sidebar or try to resume it.
  7. The Codex UI fails to open the conversation and displays a generic error page.

Expected Result

A completed thread with a valid rollout JSONL and task_complete should remain readable and resumable from the sidebar.

Actual Result

The thread becomes inaccessible from the sidebar. The UI shows a generic failure screen. In at least one older affected thread, the underlying error was a stale-path mismatch involving:

C:\...
\\?\C:\...

Relevant Log Evidence

Around the completion time of the new affected thread, the logs show normal completion:

2026-05-16 09:10:53 UTC
codex_core::stream_events_utils: final answer emitted
codex_core::session::turn: token_limit_reached=false model_needs_follow_up=false has_pending_input=false needs_follow_up=false
rollout JSONL: task_complete

Afterwards, during startup/resume attempts, the logs show repeated backend/auth-related failures:

remote plugin sync request to https://chatgpt.com/backend-api/plugins/featured failed with status 403 Forbidden
remote plugin sync request to https://chatgpt.com/backend-api/plugins/list failed with status 403 Forbidden
startup websocket prewarm setup failed: unexpected status 403 Forbidden, url: wss://chatgpt.com/backend-api/codex/responses
failed to connect to websocket: HTTP error: 403 Forbidden, url: wss://chatgpt.com/backend-api/codex/responses
codex_core::client: falling back to HTTP
stream disconnected - retrying sampling request

There are also local skill-loading warnings during session startup:

failed to load skill ... SKILL.md: missing YAML frontmatter delimited by ---

These skill warnings may be unrelated, but they occur during the same resume/startup phase. Even if local custom skills are malformed, a completed historical thread should remain readable or degrade gracefully.

Local Checks Already Performed

  • Verified that the new affected rollout JSONL exists.
  • Verified that the rollout tail contains a normal final answer and task_complete.
  • Verified that all child subagent thread edges for the new affected thread are closed.
  • Verified that the Git commit mentioned by the final answer exists.
  • Verified that the project working tree was clean after the commit.
  • For older affected threads, tried closing stale open child edges in local SQLite state; this did not fix resume.
  • For the older stale-path thread, tried changing the stored thread rollout path from normal Windows form to extended-length \\?\ form; this also did not fix resume.

These checks suggest the problem is likely in Codex Desktop's resume/render/state layer or backend-auth integration after the update, not simply an unfinished local task or a corrupt missing rollout file.

Impact

This blocks access to active project history in Codex Desktop. The affected user loses the ability to reopen important working threads after they complete, including a new thread created after the update.

Privacy Note

Raw local logs should not be attached publicly without redaction. They may contain:

  • local filesystem paths
  • account identifiers or email addresses
  • environment variables
  • token-like secrets

Sanitized log excerpts and screenshots can be provided through a secure OpenAI support channel.

Attachments To Provide

  • Screenshots of the sidebar thread and the generic error screen.
  • Sanitized log excerpts around:
  • 2026-05-16 09:10:53 UTC
  • subsequent resume/startup attempts
  • A sanitized tail excerpt of the affected rollout JSONL showing the final answer and task_complete.
  • Sanitized state rows for the affected thread ids from local Codex SQLite state.

Hypothesis

There may be a regression in Codex Desktop after the recent update involving thread resume state, path normalization, or backend-auth/WebSocket/plugin startup behavior. The older explicit error shows a normal Windows path versus an extended-length Windows path. The newer post-update thread no longer exposes the same detailed error in the UI, but it fails in the same user-facing way despite a clean completed local thread state.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 2 months ago

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

  • #22971
  • #22854
  • #22403
  • #21898
  • #22981

Powered by Codex Action

MekuraRabbit · 2 months ago

I may be hitting the same or a closely related issue.

Environment:

  • OS: Windows 11 Pro in Settings
  • Get-ComputerInfo reports:
  • WindowsProductName: Windows 10 Pro
  • WindowsVersion: 2009
  • OsBuildNumber: 26200
  • Subscription: ChatGPT Pro
  • Codex app package:
  • Name: OpenAI.Codex
  • Version: 26.513.3673.0
  • PackageFullName: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
  • Additional versions observed in logs:
  • app-server: 0.131.0-alpha.9
  • primary runtime bundle: 26.515.10909

Symptoms:

  • Existing local chats started opening to the generic "An error occurred" screen.
  • Reinstalling the app did not fix it.
  • Running wsreset.exe and checking Microsoft Store updates did not fix it.
  • Renaming/resetting local Codex profile/cache allowed the app to launch and create new chats again.
  • Restoring old sessions made chats appear in the sidebar, but opening them still showed the same error.
  • After starting from a cleaner state, a newly-created project thread also later became unreadable with the same generic error screen.

This seems similar to this issue because it is not limited to old pre-update history. A new project thread can also become inaccessible after initially working.

Relevant log pattern around the failure, with local paths omitted:

~~~text
thread/list -> success
thread/read -> success
thread/resume -> success
thread/goal/get -> errorCode=-32600
~~~

I also saw this during startup:

~~~text
unsupported feature enablement auth_elicitation: currently supported features are apps, memories, mentions_v2, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation
~~~

Workarounds tried:

  • Reinstalled Codex from Microsoft Store.
  • Ran wsreset.exe.
  • Renamed/reset .codex state/index files.
  • Renamed/reset Codex app cache under %LOCALAPPDATA%\Packages\OpenAI.Codex_...\LocalCache.
  • Renamed/reset runtime/bin cache under %LOCALAPPDATA%\OpenAI\Codex.
  • Started with a fresh .codex profile.
  • Restored only sessions from the old profile.

A fresh profile can temporarily create/open new chats, but project threads can become unreadable again.

I am avoiding attaching raw local logs or session files publicly because they may contain local paths, repository content, or secrets, but I can provide sanitized excerpts or full logs through a private support channel if helpful.

MekuraRabbit · 2 months ago

Update with another sanitized log pattern from a newly-created project thread.

In addition to the earlier thread/goal/get -> errorCode=-32600 pattern, I now see repeated renderer-side state loss for the active project thread:

~~~text
Received item/started for unknown conversation
Received item/completed for unknown conversation
No turns for conversation
Conversation state not found
~~~

This happens repeatedly for the same conversationId while project/tool/browser activity is ongoing. Some operations such as thread/name/set can still succeed, so it does not look like a complete transport failure. It looks more like the Desktop UI/renderer loses or drops the conversation state while the app-server/runtime continues sending turn/item events for that conversation.

This may explain why plain new chats can work, but development/project threads become unreadable after tool/browser/git activity.

John-Dox · 2 months ago

I am seeing what looks like a closely related issue on Windows.

Environment:

  • Codex App: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
  • Platform: Windows 10 x64
  • Installed from Microsoft Store / winget
  • Installed package: Codex [9PLM9XGG6VKS]
  • Runtime selected in logs: codex-primary-runtime 26.515.10909
  • App-server version reported in logs: 0.131.0-alpha.9

What happens:

After updating/reinstalling Codex Desktop, the app launches and the sidebar loads, but the main view shows “Something went wrong”.

The buttons shown are “Check for updates” and “Retry”. Retrying does not fix it.

The issue is reproducible every time after launching the app.

What I already tried:

I tried to rule out a local installation/cache problem.

  1. Uninstalled the Codex desktop app.
  2. Verified that the Microsoft Store/AppX package was no longer installed.
  3. Renamed/removed local Codex app data directories, including %LOCALAPPDATA%\Codex, %LOCALAPPDATA%\OpenAI\Codex, and %APPDATA%\Codex.
  4. Reinstalled Codex from Microsoft Store via winget using: winget install Codex -s msstore
  5. Verified that the installed AppX package is: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
  6. Launched the app again.
  7. Same error.
  8. Renamed the regenerated runtime directory under %LOCALAPPDATA%\OpenAI\Codex.
  9. Relaunched the app so it would recreate/download runtime files.
  10. Same error again.

This makes it look less like a stale local cache problem and more like an app/runtime/feature-flag mismatch or an issue with data loaded from the account/server side.

Relevant log excerpts:

The local logs repeatedly show this error:

unsupported feature enablement auth_elicitation: currently supported features are apps, memories, mentions_v2, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation

They also show:

Failed to sync experimental feature enablement error={"code":-32600,"message":"unsupported feature enablement auth_elicitation: currently supported features are apps, memories, mentions_v2, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation"} hostId=local

I also see this renderer/console error:

Error: invalid syntax at line 1 col 5:

1 cwd="C:\Users\<redacted>\Documents\GitHub\<redacted>"
^

The stack trace includes references to markdown/rendering components, including marked.esm, markdown, and review-file-source-tab.

Before the UI error, the logs show successful app-server responses such as:

method=thread/list errorCode=null
method=thread/read errorCode=null
method=account/read errorCode=null
method=config/read errorCode=null

The app also appears to load remote/API data successfully in general; I see HTTP 200 responses for several backend calls, including task/thread-related calls.

Why I think this may be related:

The app seems to start correctly and connect to the local app server, but the main UI fails after reading account/thread data and syncing experimental feature enablement.

The repeated auth_elicitation unsupported-feature error looks very similar to what other reports mention, and the issue persists even after a clean reinstall and after removing regenerated local app data/runtime directories.

I can provide more redacted log excerpts if useful.

wowfraga-eng · 2 months ago

The issue has been resolved after the latest Codex update. Large archived conversations are now accessible again and open correctly.

Current installed version: 26.513.4821.0.

I’m closing this issue since everything is working now.

ckribrahim · 2 months ago

I have the same issue on Windows 11 after updating to 26.513.31313. Sessions crash after a while and become inaccessible.

etraut-openai contributor · 2 months ago

We've release a hotfix to address this. Please install the update.