Codex Desktop Windows 26.616: local project threads appear, but opening one marks cwd missing and collapses project sidebar to No chats

Open 💬 4 comments Opened Jun 19, 2026 by mpknott

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 cwd values are \\?\C:\...,
explicit thread-workspace-root-hints are missing, incomplete, or not enough to override cwd,
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 chats while Search/local data still works
#22796 — Project sidebar shows No chats while 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.sqlite
session_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 chats after 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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

#28348
#28094
#27516

Powered by Codex Action

cyformatician · 2 months ago

Confirmed for both native and WSL modes.

BorisSavage · 1 month ago

TL;DR

I hit what looks like the same Windows Desktop project-sidebar collapse. In my case, the chats were not deleted; existing local history was still present, but project grouping failed because Codex had mixed incompatible cwd / project-root path dialects across local state.

Important: I have WSL installed on this machine, but I did not intentionally configure Codex into a split WSL/native-Windows setup. The evidence suggests Codex created, preserved, or failed to reconcile that split across Desktop/CLI/runtime updates and restarts.

The broken state involved path forms such as:

/mnt/c/Users/<user>/...
C:\Users\<user>\...
\\?\C:\Users\<user>\...
C:\mnt\c\Users\<user>\...
/mnt/c/Program Files/WindowsApps/OpenAI.Codex_.../app/resources/C:\Users\<user>\...

The durable repair was not just editing one DB column. First repairs normalized state_5.sqlite, sqlite/codex-dev.db, global project roots/hints, thread assignments, rollout metadata, and config into a consistent WSL-style state. The final durable step was to migrate those active path surfaces atomically from WSL-style /mnt/c/Users/... paths to native Windows C:\Users\... paths and set runCodexInWindowsSubsystemForLinux = false.

Environment

Platform: Windows 11 / x64
Codex Desktop / MSIX
Broken state observed around:
App package: OpenAI.Codex_26.623.4041.0_x64__2p2nqsd0c76g0
CLI/runtime: break appeared after updating from around 0.138.0 to 0.142.2
Later working state after local repair + app update:
App package observed: OpenAI.Codex_26.623.8305.0_x64__2p2nqsd0c76g0
CLI/runtime during final verification: 0.142.2 on Windows; update check reported 0.142.4 available
WSL is installed/configured on the machine, but I did not deliberately set up Codex to split project state between WSL and native Windows paths.
Projects were local Windows user-profile projects, with equivalent path forms such as:
C:\Users\<user>\...\project
/mnt/c/Users/<user>/.../project

User-visible symptom

Saved projects were still visible in the Codex Desktop sidebar, but all project panes showed No chats.

The behavior matched this issue closely:

After app launch, project panes sometimes briefly populated.
After a short refresh/hydration step, project panes collapsed to No chats.
Existing chats were still searchable/resumable, so this looked like grouping/indexing failure rather than total local-history loss.

Important timing detail

In my case the break appears to have started when I updated the CLI/runtime from around 0.138.0 to 0.142.2, not only after a visible Desktop app update.

At least one affected session had old rollout metadata like:

cli_version: 0.138.0-alpha.7
originator: Codex Desktop
source: vscode

The newer 0.142.x runtime appears to have consumed legacy Windows session_meta.payload.cwd values differently and produced malformed or inconsistent cwd values that the Desktop sidebar later grouped on.

So this may be a migration/compatibility bug between older session metadata and newer CLI/app-server/runtime behavior, not only a renderer/sidebar display bug.

Key local finding

The live Desktop renderer had thread/conversation objects whose cwd had been transformed into this malformed shape:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.623.4041.0_x64__2p2nqsd0c76g0/app/resources/C:\Users\<user>\...\project

That path obviously cannot match any saved project root. As a result, the sidebar grouping logic treated existing chats as outside their projects, and the project panes rendered as No chats.

This looks related to #23189, except my malformed suffix was a normal C:\Users\... path rather than a \\wsl$\... path.

Data was not deleted

Local checks showed that the chats still existed:

.codex/state_5.sqlite still contained thread rows.
.codex/sessions/**/*.jsonl rollout files still existed.
.codex/session_index.jsonl still listed sessions.
The affected threads were not archived.
During repair, a live GUI React-state probe showed roughly the expected thread set still loaded, for example recentRenderableCount: 96.
The app-server/SQLite state could return target threads after cwd repair.
SQLite integrity checks were ok.

After the durable native-Windows repair, verification showed:

state_5.sqlite integrity: ok
sqlite/codex-dev.db integrity: ok
state_5.sqlite thread count: 580
local_thread_catalog row count: 96
active app/resources cwd count: 0
active C:\mnt\c\Users\... path values: 0
known target thread paths normalized correctly: true
app-server project filters returned non-empty results: true

codex doctor still reported a warning that some rollout files were missing from the state DB, but those were internal guardian/subagent/exec or archived rollout files. They were not the user-facing project chats that had disappeared from panes.

Local stores involved

The issue was not isolated to one store. Relevant local state existed across:

~/.codex/state_5.sqlite
~/.codex/sqlite/codex-dev.db
~/.codex/.codex-global-state.json
~/.codex/session_index.jsonl
~/.codex/sessions/**/*.jsonl
Codex Desktop / Electron renderer state

Some stores had already-correct values while the live Desktop renderer still had stale/malformed cwd values. That made “SQLite looks correct” insufficient to guarantee that the sidebar would group correctly.

Path forms observed during the incident

Equivalent roots appeared in multiple string forms:

C:\Users\<user>\...\project
C:\mnt\c\Users\<user>\...\project
/mnt/c/Users/<user>/.../project
/mnt/c/users/<user>/.../project
\\?\C:\Users\<user>\...\project
/mnt/c/Program Files/WindowsApps/OpenAI.Codex_.../app/resources/C:\Users\<user>\...\project

The project sidebar appears to rely on normalized project-root/cwd matching. If any of these forms fail to canonicalize to the same project key, existing chats can become invisible under their project.

One nuance from the final working state: \\?\C:\Users\... was not fatal by itself. Some state_5.sqlite cwd rows used that extended-prefix form after repair, but app-server normalized them back to C:\Users\... and project filtering worked. The fatal issue was the split across incompatible dialects, especially C:\mnt\c\Users\... and the app/resources/C:\Users\... malformed path.

What fixed it

There were two repair stages.

First, a WSL-mode repair normalized legacy Windows cwd values in rollout JSONL session metadata. Many rollout JSONL files had old session_meta.payload.cwd values stored as Windows paths:

C:\Users\<user>\...\project

After the newer runtime/app consumed them, the live cwd could become:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_.../app/resources/C:\Users\<user>\...\project

A structural repair converted only session_meta.payload.cwd values from Windows form to WSL form, for example:

C:\Users\<user>\...\project
-> /mnt/c/Users/<user>/.../project

That repair changed:

568 rollout JSONL files
933 session_meta.cwd values

This helped restore many project panes, but it was not the final durable fix. At one point, after Windows sleep/wake, Codex showed an Electron-style renderer reload error. Clicking Reload reopened the app, but project panes were almost all empty again. A full app restart restored the panes.

Separately, while investigating repeated local tool-call failures that the agent had to retry or rephrase, I discovered that my Codex install had ended up in a split WSL/native-Windows setup. When iterating on this, the project panes became empty again. That split turned out to be directly relevant. The final durable repair was an audited native-Windows migration.

At the time of migration, the dry run showed planned normalization of:

state_5.sqlite threads.cwd: 579 rows -> C:\Users\...
sqlite/codex-dev.db local_thread_catalog.cwd: 96 rows -> C:\Users\...
.codex-global-state.json thread-workspace-root-hints: 567 values -> C:\Users\...
session metadata: 587 files, 1318 path-metadata lines
config.toml runtime flag: runCodexInWindowsSubsystemForLinux = false

The final repaired state used native Windows paths consistently for active project/thread metadata:

C:\Users\<user>\...

and rejected the invalid transition form:

C:\mnt\c\Users\<user>\...

The active path surfaces that had to be consistent were:

state_5.sqlite, table threads.cwd
sqlite/codex-dev.db, table local_thread_catalog.cwd
.codex-global-state.json
electron-saved-workspace-roots
project-order
thread-workspace-root-hints
thread-project-assignments
active-workspace-roots
rollout JSONL metadata fields such as:
session_meta.payload.cwd
turn_context.payload.cwd
turn_context.payload.workspace_roots
config.toml
runCodexInWindowsSubsystemForLinux = false
active local source/tool paths converted to Windows-readable paths
no WSLENV
no active C:\mnt\c\...

After this, app-server project filters returned the expected project threads.

During debugging, some individual threads could still be found through direct search/app-server queries even while project panes were empty. I would not treat that as a true project-level exception; it looked more like different local sources winning during hydration at different moments. The consistent user-visible failure was that saved project panes could collapse to No chats despite the underlying thread files and DB rows still existing.

Hypothesis

This looks like a migration/compatibility bug triggered by newer Codex CLI/app-server/runtime reading older local session metadata, combined with incomplete reconciliation between WSL-mode and native-Windows-mode local state.

The likely chain in my case was:

Older Desktop/CLI wrote session_meta.payload.cwd as C:\Users\<user>\....
Runtime was updated from around 0.138.0 to 0.142.2.
Newer runtime/Desktop hydration interpreted legacy Windows cwd values relative to the packaged app resource directory.
Live thread cwd became:

``text /mnt/c/Program Files/WindowsApps/OpenAI.Codex_.../app/resources/C:\Users\<user>\...\project``

Project grouping failed because saved project roots could not match that malformed cwd.
Subsequent partial repairs or runtime-mode changes exposed another invalid dialect:

``text C:\mnt\c\Users\<user>\...``

Sleep/wake or renderer reload could rehydrate bad state and collapse panes to No chats.
Full app restart could restore grouping, depending on which local source won during hydration.
The stable fix required migrating all active path surfaces together.

Suggested fix direction

The app probably needs a migration/backfill step that canonicalizes project/thread cwd values across all local sources.

At minimum, it should normalize and reconcile:

state_5.sqlite threads.cwd
local thread catalog DB metadata, if applicable
.codex-global-state.json saved project roots
thread-workspace-root-hints
thread-project-assignments
session_meta.payload.cwd in rollout JSONL
renderer/app-server caches derived from those values
config.toml runtime mode and active local source/tool paths

The sidebar should probably group by a canonical project identity/key instead of exact raw cwd strings.

Equivalent forms should collapse to the same key, including:

C:\Users\<user>\...
\\?\C:\Users\<user>\...
/mnt/c/Users/<user>/...
/mnt/c/users/<user>/...

This form should be treated as invalid and repaired, not preserved as native Windows:

C:\mnt\c\Users\<user>\...

This malformed form should also be detected and repaired explicitly:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_.../app/resources/C:\Users\<user>\...

That should be interpreted as a bad resource-relative Windows path and normalized back to the captured Windows path, not treated as a real project cwd.

Conclusion

The UI made it look like project history was lost, but the local history was still present. The failure was in migration/hydration/grouping.

A built-in repair tool or automatic backfill would prevent users from manually editing .codex state, restoring backups, or assuming their chats were deleted.

mpknott · 1 month ago

Adding more evidence because my prior email reply appears to have bounced from [[notifications@github.com](mailto:notifications@github.com)](mailto:notifications@github.com) with a mailbox quota error.

I performed a staged local-state reset on Windows Codex Desktop.

Environment:

Windows Codex Desktop: 26.616.4196.0
Windows user path: C:\Users\Mike
Remote target: agents-lab over SSH
agents-lab SSH worked outside Codex
PIA VPN was disabled during testing

Results:

Soft reset only:

Moved aside AppData\Local\Codex
Moved aside AppData\Local\OpenAI
Left C:\Users\Mike.codex in place

Result:

Computer Use still showed:

“Invalid request: AbsolutePathBuf deserialized without a base path”

Full reversible local reset:

Moved aside C:\Users\Mike.codex
Moved aside AppData\Local\OpenAI
AppData\Local\Codex had already been moved aside

Result:

Codex Desktop behaved like a fresh setup.
The Computer Use / AbsolutePathBuf error disappeared.
agents-lab could be re-authenticated successfully.
SSH connections became green again.

Session-only restore:

Restored only:

C:\Users\Mike.codex\sessions\
C:\Users\Mike.codex\session_index.jsonl
Did not restore:

state_5.sqlite
state_5.sqlite-wal
state_5.sqlite-shm
.codex-global-state.json
computer-use\config.json
plugins\cache
.tmp

Observed result:

Old chats became searchable from Search.
Example searches such as “job”, “bridge”, “.codex”, and “applications” returned older sessions/projects.
Sidebar/recent chat list only partially repopulated and did not fully restore old project grouping.
Computer Use error did not return after restoring only sessions and session_index.jsonl.

Interpretation:

sessions\ and session_index.jsonl appear sufficient for Search to find old sessions.
Sidebar/project/recent chat grouping appears to depend on additional local state, likely state_5.sqlite or related metadata.
The problematic state appears to be in .codex, not AppData alone.
This appears consistent with mixed Windows/WSL/extended-path state causing project/sidebar grouping and Computer Use deserialization failures.