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

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:

  1. Sometimes the threads appear after launch and then disappear automatically without any click or interaction.
  2. 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

  1. Open Codex Desktop on Windows.
  2. Wait a few seconds for the sidebar to populate.
  3. Observe that saved local project groups initially show existing threads.
  4. Do not click anything.
  5. After a short refresh, affected local project groups switch to No chats.

Reproduction path B: thread-open failure

  1. Open Codex Desktop on Windows.
  2. Wait a few seconds for the sidebar to populate.
  3. Observe that saved local project groups initially show existing threads.
  4. Click one thread under an affected local project rooted under %USERPROFILE%\Documents\....
  5. The selected thread opens successfully in the main pane.
  6. 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:

  1. project threads visible before refresh/click,
  2. project groups changed to No chats after refresh/click,
  3. 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 ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗