Codex Windows app stuck on blank/spinner at startup — unsupported `workspace_dependencies` feature loop
What version of the Codex App are you using (From “About Codex” dialog)?
Latest version from official installer (MS Store / AppInstaller flow) Exact version not accessible via UI due to startup failure. Logs indicate runtime bundle version: 26.423.10653
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Codex Windows desktop app fails to load the UI and gets stuck on a blank/spinner screen on startup.
Behavior:
- App launches
- UI briefly flashes (main interface visible for a split second)
- Then transitions into a blank screen with spinner
- App becomes unusable
This occurs consistently on every startup after a recent update.
Logs show a repeated failure loop where the renderer attempts to enable an experimental feature (workspace_dependencies), but the runtime rejects it.
This results in continuous retries and prevents the UI from stabilizing.
This error is persistent across ALL logs from today, across multiple restarts and attempts.
What steps can reproduce the bug?
This is not inherently reproducible yet from my findings, as the bug does not persist across two devices (self-built computer on ASUS Rog strix B550 motherboard, vs Lenovo YOGA laptop)
- Update Codex Windows app via official installer (MS Store/AppInstaller downloaded from codex page)
- Launch the application
- Wait for UI initialization
Observed:
- UI briefly flashes
- Then transitions to blank screen with spinner
- App does not recover
This behavior is consistent across multiple launches.
No specific user interaction is required to trigger the issue.
What is the expected behavior?
Codex app should successfully initialize and display the main UI after startup.
No repeated error loops should occur, and the renderer should not continuously retry failed feature enablement.
The app should remain usable after launch.
Additional information
Relevant log excerpt (repeats continuously across all logs from today):
2026-04-24T19:30:47.843Z info [electron-message-handler] Handled 'ready' message, sent ide-context-updated
2026-04-24T19:30:47.880Z error [electron-message-handler] Request failed conversationId=none durationMs=65 error={"code":-32600,"message":"unsupported feature enablement `workspace_dependencies`: currently supported features are apps, memories, plugins, tool_search, tool_suggest, tool_call_mcp_elicitation"} id=7fa1110e-2520-484a-83a8-0e3d36a51cc3 method=experimentalFeature/enablement/set pendingCountAfter=1 timeoutMs=0
2026-04-24T19:30:47.880Z error [electron-message-handler] Failed to sync experimental feature enablement error={"code":-32600,"message":"unsupported feature enablement `workspace_dependencies`: currently supported features are apps, memories, plugins, tool_search, tool_suggest, tool_call_mcp_elicitation"} hostId=local
2026-04-24T19:30:47.931Z info [AppServerConnection] response_routed broadcastFallback=false conversationId=null durationMs=0 errorCode=-32600 hadInternalHandler=false hadPending=true method=experimentalFeature/enablement/set originWebcontentsId=1 requestId=37b87dd1-ed4f-49c2-b748-80a8b8af282d targetDestroyed=false
2026-04-24T19:30:47.958Z info [electron-message-handler] [startup][renderer] app routes mounted after 665251ms
This loop repeats hundreds of times and generates large log files (~10MB per session).
Troubleshooting attempted:
- Cleared UI cache (
LocalCache\Roaming\Codex) - Reset
.codex-global-state.json - Restarted app multiple times
- Reinstalled via official installer
No change.
Related issues / possible duplicates:
- #19279 (similar feature mismatch loop, different platform)
- #19220 (startup failure with same unsupported feature error)
This appears to be a renderer/runtime feature mismatch, where the desktop app expects support for workspace_dependencies but the runtime does not provide it.
Pasted three most recent logs from startup attempts (yes they are huge, this is a separate issue):
codex-desktop-2ba6edfb-2b1a-4196-a433-33d046f45288-13448-t0-i1-191942-1.log
codex-desktop-2ba6edfb-2b1a-4196-a433-33d046f45288-13448-t0-i1-191942-2.log
codex-desktop-2ba6edfb-2b1a-4196-a433-33d046f45288-13448-t1-i1-191944-0.log
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
After starting Codex CLI, I got an error message of an expired auth_token.
That gave me a hunch.
So I signed in through the codex CLI, and then tried restarting the desktop app. And it worked!
The error from the CLI (de-noised with ChatGPT):
I then ran:
After signing in again, I restarted the Windows desktop app, and the app successfully loaded.
So the workspace_dependencies loop may have been a secondary symptom. The underlying trigger appears to have been expired authentication causing MCP / app feature synchronization to fail during startup.
After re-authentication, the repeated unsupported feature enablement workspace_dependencies startup loop no longer appears in the latest logs.
Suggested root cause:
Expired auth token → MCP/app sync failure → feature enablement sync fails/retries → desktop UI gets stuck on blank/spinner.
I’m leaving this issue open because the desktop app did not surface an auth-expired error and instead became unusable.
Codex Desktop Chat and Project Recovery Guide
This guide documents a conservative recovery process for Codex Desktop and Codex CLI session context after a failed troubleshooting or reset sequence.
It is based on a Windows recovery where Codex Desktop had previously failed to load after an update, showing a blank/spinner startup loop. The related GitHub issue was:
https://github.com/openai/codex/issues/19437
The issue title was:
Codex Windows app stuck on blank/spinner at startup - unsupported workspace_dependencies feature loopThe recovery goal is to restore chat/session visibility and project/workspace visibility without deleting data permanently.
---
Safety Rules
Use these rules throughout the process:
sessionsorarchived_sessionsunless they are actually missing.auth.jsonas sensitive account data.---
Relevant Data Locations
Use environment variables instead of hard-coded personal paths.
Codex CLI and session data:
Common files and folders under
%USERPROFILE%\.codex:Codex Desktop UI state is usually under the Windows app package cache:
Some runtime logs or Electron state may refer to:
If
%APPDATA%\Codexdoes not exist, that is not necessarily a problem. On some installs the active state is stored under the packageLocalCache\Roaming\Codexpath.---
What Each File Does
The most important files for recovery are:
| Path | Purpose | Restore priority |
| --- | --- | --- |
|
sessions| Main Codex CLI chat/session JSONL files | High ||
archived_sessions| Archived chat/session JSONL files | High ||
session_index.jsonl| CLI-visible session index used by resume/listing | High ||
.codex-global-state.json| Desktop UI workspace/project/pinned-thread state | High ||
state_5.sqlite| Codex runtime state database | Medium ||
logs_2.sqlite| Codex runtime logs database | Low/diagnostic ||
auth.json| Authentication state | Sensitive ||
config.toml| CLI configuration | Medium |In the documented recovery,
sessionsandarchived_sessionswere intact. The CLI problem was thatsession_index.jsonlwas missing. The Desktop project/sidebar problem was that.codex-global-state.jsonhad been reset to a smaller file missing workspace roots, pinned threads, and project order.The successful recovery restored only:
The following were intentionally left untouched:
---
Step 1: Close Running Codex Processes
Before changing files, inspect running processes.
The safest practical approach is:
Read-only process inspection:
If Codex Desktop is still running, close it normally from the window first. If it is stuck, stop only the Codex Desktop process tree, not unrelated apps and not the active recovery CLI session.
---
Step 2: Back Up Relevant Chat and Project Data
Create backups before logout/login, reset, reinstall, or restore operations.
This backs up the main
.codexdirectory and the Desktop UI state directory:Optional: back up only the most important files into a smaller recovery bundle.
Do not upload this backup to GitHub, Discord, issue trackers, or support channels without reviewing and redacting it.
---
Step 3: Log Out and Log Back In to Codex
Use logout/login only after backing up data.
For Codex CLI:
If the app is broken but CLI still works, verify CLI authentication:
Then start a new CLI session or resume a known session:
If
codex resume <session-id>works, the chat file still exists and the core CLI session data is recoverable.If CLI cannot list or find older sessions but
codex resume <session-id>works, suspectsession_index.jsonl.---
Step 4: Restart Codex Desktop and Verify
After login or restore:
Expected success signs:
If Desktop opens but projects are gone, do not reset again. Follow the recovery section below.
---
Step 5: Locate Available Backups
Look for full
.codexbackups:Look for Desktop UI backups:
Look for global state backups:
Read-only backup inventory:
Do not assume the newest file is correct. Compare size, timestamp, and contents.
---
Step 6: Compare Current State Against Backups
Check whether the current session files are missing or whether only the index/UI state is broken.
Important comparison questions:
.codex\sessionscontain the expected JSONL files?.codex\archived_sessionscontain the expected archive files?session_index.jsonlmissing, empty, or much smaller than backup?.codex-global-state.jsonmuch smaller than backup?.codex-global-state.jsoncontain keys likeelectron-saved-workspace-roots,active-workspace-roots,pinned-thread-ids, andproject-order?Read-only metadata comparison:
If current
sessionshas all backup sessions plus newer sessions, do not replace it.---
Step 7: If Projects Are Gone in Desktop
If Codex Desktop opens but projects, pinned chats, or workspace roots are gone, the likely file is:
This file can contain:
Recovery approach:
.codex-global-state.json..codex-global-state.jsonfrom a known-good backup.Preserve and restore global state:
If you only have a full
.codex_backup_<timestamp>folder, use:---
Step 8: If CLI Chats Are Gone or Not Listed
If session files still exist but CLI listing/resume visibility is broken, check:
Symptoms of a broken or missing index:
Recovery approach:
session_index.jsonlif it exists.session_index.jsonlfrom full.codexbackup.sessionshas newer sessions not present in the backup, append index records for those current-only sessions.The index format is JSONL. Each non-empty line is similar to:
Simple restore when no newer current sessions need to be preserved:
If current
sessionscontains sessions newer than the backup, restore the backup index but append records for those current-only sessions. Use thread names that are redacted or generic if the index will be shared.Example appended records:
---
Step 9: If Session Files Are Actually Missing
If current
sessionsorarchived_sessionsis missing files that exist in backup, restore only the missing folders or files.Avoid replacing a current folder wholesale if it contains newer sessions. Prefer copying missing files from backup into the current folder.
Safe folder merge pattern:
Repeat the same idea for:
---
Step 10: SQLite Files
Do not replace SQLite files first if JSONL session files and global state are enough to recover visibility.
These files may be locked while Codex CLI or Desktop is running:
Only restore them if:
session_index.jsonland.codex-global-state.jsondid not fix the issue.If SQLite files are locked, close Codex Desktop and any Codex CLI sessions, then retry. Do not force-copy over locked databases.
---
Step 11: Verification
Verify CLI recovery:
Verify Desktop recovery:
Verify restored files exist:
Expected result after the documented recovery:
---
Troubleshooting Matrix
| Symptom | Likely cause | First recovery action |
| --- | --- | --- |
| Desktop opens but projects are gone | Reset
.codex-global-state.json| Restore.codex-global-state.jsonfrom backup || CLI can resume by ID but old chats are not listed | Missing or stale
session_index.jsonl| Restore or rebuildsession_index.jsonl|| CLI cannot resume a known session ID | Session JSONL may be missing | Check
sessionsand restore missing JSONL files || Desktop blank/spinner after update | App/runtime issue similar to issue #19437 | Back up data, log out/in, restart, then restore UI state if needed |
| SQLite files cannot be copied | Codex process has database lock | Close Desktop and CLI before touching SQLite |
| Restored UI state still does not show projects | Wrong backup or app overwrote state on launch | Close Desktop, compare backup global state, restore again from known-good backup |
---
Notes on Redaction
Before sharing logs, screenshots, or backups, redact:
Use placeholders:
Good redacted path examples:
Avoid publishing unredacted examples like:
---
Known-Good Minimal Recovery Pattern
The minimal successful recovery pattern was:
sessionscontained all backup sessions plus newer sessions.archived_sessionsmatched backup.session_index.jsonlwas missing.session_index.jsonlexisted..codex-global-state.jsonwas reset-looking and missing project/workspace keys..codex-global-state.jsoncontained project/workspace keys.session_index.jsonl..codex-global-state.json.This worked because the underlying chat files were still present. The failure was primarily an index/UI-state visibility problem, not a data-loss problem.
Possible Windows fix: enable Developer Mode for runtime extraction failures
I ran into a similar Codex Desktop runtime installation failure on Windows.
The logs showed repeated primary runtime install failures like: