Codex Desktop Windows 26.616: local project threads appear, but opening one marks cwd missing and collapses project sidebar to No chats
What version of the Codex App are you using?
26.616.4196.0
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
Windows 11 Pro, Version 25H2, OS build 26200.8655
---
What issue are you seeing?
Codex Desktop on Windows 26.616.4196.0 initially shows existing local project threads under saved local project groups. After a short refresh, affected local project groups collapse to No chats.
This happens in two ways:
- Sometimes the threads appear after launch and then disappear automatically without any click or interaction.
- If I click a thread under an affected local project before the refresh happens, the thread opens in the main pane, then Codex immediately removes visible thread entries from affected local project groups in the left sidebar and shows
No chats.
When the clicked thread opens, the main pane displays:
current working directory missing
This chat's working directory no longer exists
Local diagnostics show the working directory does exist on disk. This appears to be a Windows Codex Desktop path-normalization / project-to-thread mapping / sidebar refresh bug, not actual data loss and not an actually missing folder.
Important observation: one local/internal .codex project thread remained visible and persisted after clicking it. The disappearing behavior appears focused on local document/project roots under %USERPROFILE%\Documents\..., not every sidebar entry universally.
---
What steps can reproduce the bug?
Reproduction path A: automatic refresh failure
- Open Codex Desktop on Windows.
- Wait a few seconds for the sidebar to populate.
- Observe that saved local project groups initially show existing threads.
- Do not click anything.
- After a short refresh, affected local project groups switch to
No chats.
Reproduction path B: thread-open failure
- Open Codex Desktop on Windows.
- Wait a few seconds for the sidebar to populate.
- Observe that saved local project groups initially show existing threads.
- Click one thread under an affected local project rooted under
%USERPROFILE%\Documents\.... - The selected thread opens successfully in the main pane.
- Immediately afterward:
- the clicked thread disappears from the left sidebar,
- other affected local project groups switch to
No chats, - the main pane shows
current working directory missing, - Codex says
This chat's working directory no longer exists.
Control observation
Clicking an internal/local .codex project thread does not reproduce the same disappearing behavior. That thread remains visible.
This suggests the issue is specific to local document/project root resolution or thread-to-project mapping, not a universal sidebar rendering failure.
---
What is the expected behavior?
If a local project thread exists and its working directory exists on disk, opening the thread should not cause Codex to:
- mark the working directory as missing,
- remove that thread from the project group,
- collapse other local project groups to
No chats.
Codex should normalize equivalent Windows path forms and preserve the project-to-thread mapping.
For example, Codex should treat these as the same real folder:
C:\Users\<redacted>\Documents\Project
\\?\C:\Users\<redacted>\Documents\Project
The sidebar should continue showing the existing local project threads after launch, refresh, or opening one of them.
---
Additional information
Environment
Product: Codex Desktop app
Platform: Windows 11 x64
Windows version: Windows 11 Pro, Version 25H2, OS build 26200.8655
Platform string: Microsoft Windows NT 10.0.26200.0 x64
Installed app package: OpenAI.Codex 26.616.4196.0
Package full name: OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0
Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0
Codex home: %USERPROFILE%\.codex
Local state DB: %USERPROFILE%\.codex\state_5.sqlite
Shell used for diagnostics: PowerShell 7.6.3
Subscription: ChatGPT Plus
---
Local diagnostic evidence
1. The affected project folders exist
Read-only diagnostics show the local project folders exist:
C:\Users\<redacted>\Documents\Job Applications
C:\Users\<redacted>\Documents\Job Applications\<Affected Project>
C:\Users\<redacted>\Documents\PCCS Writing System
C:\Users\<redacted>\Documents
All returned:
exists_as_recorded = true
is_dir_as_recorded = true
2. The thread cwd paths also resolve
Affected threads.cwd values in state_5.sqlite use extended Windows path form, for example:
\\?\C:\Users\<redacted>\Documents\Job Applications
\\?\C:\Users\<redacted>\Documents\Job Applications\<Affected Project>
\\?\C:\Users\<redacted>\Documents\PCCS Writing System
Read-only diagnostics showed these paths exist as recorded:
exists_as_recorded = true
is_dir_as_recorded = true
So the app's current working directory missing banner is not accurate in the file-system sense.
3. Active workspace root and thread cwd differ only by path representation
After opening the affected project thread, global state showed the active workspace root in canonical form:
C:\Users\<redacted>\Documents\Job Applications\<Affected Project>
But the thread row in SQLite used extended path form:
\\?\C:\Users\<redacted>\Documents\Job Applications\<Affected Project>
These refer to the same folder, but Codex appears to treat them as non-equivalent when opening the thread.
4. Thread workspace-root hints appear incomplete
Diagnostics initially showed:
thread_workspace_root_hint_count = 4
thread_workspace_root_hints_related = []
So affected local project threads appeared to lack explicit thread-workspace-root-hints entries even though their cwd values and saved workspace roots were present.
This may be part of the sidebar/project-to-thread mapping failure.
5. SQLite integrity is OK
SQLite reported:
integrity = ok
journal_mode = wal
This does not look like database corruption.
---
Prior local repair experiments already tried
I tried several local-state repair experiments before filing this report.
Static canonicalization
Canonicalized local roots across:
%USERPROFILE%\.codex\config.toml
%USERPROFILE%\.codex\.codex-global-state.json
%USERPROFILE%\.codex\chrome-native-hosts-v2.json
%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json
%USERPROFILE%\.codex\state_5.sqlite
Result: local project threads still disappeared after Codex refresh/open.
Parallel extended-root project test
Added an explicit project root in extended path form:
\\?\C:\Users\<redacted>\Documents\Job Applications
The state retained it, but the UI ignored/de-duplicated/filtered it and did not resolve the disappearing sidebar issue.
Replacement extended-root project test
Replaced the canonical project root with the extended root form in config.toml and .codex-global-state.json.
Result: the replacement state remained, but the UI still dropped the project chats.
SQLite trigger normalization test
Temporarily installed SQLite triggers to keep affected threads.cwd rows canonical even if Codex runtime rewrote them to \\?\C:\....
Post-launch diagnostics showed:
verdict = TRIGGERS_HELD_DATABASE_CANONICAL_BUT_UI_STILL_DROPPED_CHATS
extended_row_count = 0
canonical_row_count = 11
required_triggers_present = true
integrity = ok
So even when the database was held canonical, the UI still dropped the project chats. The test triggers were rolled back.
---
Additional controlled test: single-thread hint repair
I then ran a controlled single-thread metadata repair test against a disposable test thread:
019ed828-f473-7411-aa83-2bfd09770d80
The test set both:
threads.cwd = C:\Users\<redacted>\Documents\Job Applications
thread-workspace-root-hints[thread_id] = C:\Users\<redacted>\Documents\Job Applications
The pre-launch postcheck showed the repair applied successfully:
apply_effective = true
target_cwd_is_desired = true
hint_is_desired = true
sqlite integrity = ok
After opening Codex and letting the sidebar refresh/fail without clicking anything, I ran a read-only verification.
Result:
verdict = CODEX_RUNTIME_REVERTED_SQLITE_CWD_ONLY
Current state after Codex ran:
thread-workspace-root-hints[thread_id] = C:\Users\<redacted>\Documents\Job Applications
threads.cwd = \\?\C:\Users\<redacted>\Documents\Job Applications
The explicit thread workspace-root hint stayed in place, but Codex runtime rewrote the SQLite threads.cwd value back to extended Windows path form.
The normalized path still exists on disk:
target_cwd_normalized = C:\Users\<redacted>\Documents\Job Applications
target_cwd_normalized_exists = true
So Codex Desktop runtime appears to rewrite or persist local thread cwd values in \\?\C:\... form while other app state such as saved workspace roots and workspace-root hints may use canonical C:\... form.
This strengthens the suspicion that the Windows app is failing to normalize equivalent path forms during sidebar/project/thread reconciliation.
---
Current hypothesis
Codex Desktop on Windows is failing to reconcile local project threads when:
- saved workspace roots are canonical
C:\..., - thread
cwdvalues are\\?\C:\..., - explicit
thread-workspace-root-hintsare missing, incomplete, or not enough to overridecwd, - and the app refreshes the sidebar or opens a local project thread.
The app appears to treat equivalent paths as non-equivalent or invalid, shows current working directory missing, and refreshes the sidebar to No chats.
---
Why this is likely an app bug
The local folders exist. The SQLite rows exist. The app can initially list the threads. The failure occurs during app-side validation or refresh.
Codex should not show current working directory missing when the path exists and resolves on Windows.
Codex should also not remove all project thread entries from the sidebar after opening one valid local project thread, or after an automatic sidebar refresh.
---
Related reports / potential duplicates
Potential duplicates detected by GitHub Actions appear related but not exact duplicates:
- #28348 — related to project/sidebar mapping and
No chats, but appears broader and includes duplicate project entries and CLI-visible history. - #28094 — closest root-cause-family match because it involves valid working directories being reported missing due to path handling / path normalization problems.
- #27516 — closest behavioral match because it describes a thread reappearing and then disappearing from the project sidebar when clicked.
This issue may be another manifestation of the same broader sidebar/path-normalization bug family, but it includes additional controlled diagnostics showing that Codex runtime itself reverted the SQLite cwd value while preserving the explicit workspace-root hint.
Other related reports in openai/codex include:
- #19290 — Windows Desktop sidebar shows
No chatswhile Search/local data still works - #22796 — Project sidebar shows
No chatswhile local sessions still exist - #21581 — Desktop sidebar/search hides older local project chats although thread data still exists
- #25084 — Codex Desktop hides active project chat history while local threads remain on disk
- #27251 — Latest update partially restores history but older project histories remain missing
---
Impact
This is a data-loss-class UX problem even though the underlying data may still exist.
The affected project threads contain development history, workflow history, validation notes, generated files, and task continuity. Losing normal sidebar access makes it difficult to resume work safely.
---
Requested maintainer guidance
Please confirm whether Codex Desktop has a supported way to rebuild or repair the project-to-thread/sidebar index from durable local state, including:
state_5.sqlitesession_index.jsonl.codex/sessions- saved workspace roots
thread-workspace-root-hints- persisted permissions / writable roots
- canonical and extended Windows path variants
At minimum, Codex Desktop should normalize equivalent Windows path forms such as:
C:\Users\<redacted>\Documents\Project
\\?\C:\Users\<redacted>\Documents\Project
before deciding that a working directory is missing or before removing project threads from the sidebar.
---
Attachments
I can provide redacted screenshots showing:
- project threads visible before refresh/click,
- project groups changed to
No chatsafter refresh/click, - the main pane showing
current working directory missing.
I prefer not to upload full .codex databases, full .codex-global-state.json, or session transcript files publicly because they may contain private local project or conversation data.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗