Codex Desktop project threads disappear from project views/search while session JSONL remains readable

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

• #25084
• #25294
• #25119
• #24521
• #24364

Powered by Codex Action

I added a small privacy-safe helper for this exact class of report in trace-to-skill@0.1.72:

npx trace-to-skill@0.1.72 session-audit ~/.codex --format json

It does not repair Codex state or mutate local files. It only builds a local summary that compares rollout session metadata with session_index.jsonl, then reports:

• rollout thread count
• indexed vs unindexed rollout thread count
• recoverable codex resume <thread_id> commands
• state file presence
• hashed project groups using workspace basename + short path hash, without printing full local paths

The goal is to make issues like this easier to diagnose publicly without attaching raw transcripts, SQLite databases, or full local paths. Release/proof: https://github.com/grnbtqdbyx-create/trace-to-skill/releases/tag/v0.1.72

Additional Windows reproduction: valid local project threads remain hidden and deep links open blank

I am seeing a closely related issue on Windows with Codex Desktop where local project threads are recoverable from durable local state and resumable from the CLI, but Codex Desktop still hides some of them from the project sidebar and opens them as a blank/loading chat via codex://threads/<id>.

This comment is sanitized. Project names, local paths, thread IDs, usernames, and feedback IDs are represented with placeholders.

Environment

• Product: Codex Desktop
• Platform: Windows
• Codex Desktop version: 26.527.31326
• Project/workspace: <project-name>
• Project cwd observed in local state:
• <repo-path>
• SQLite also uses Windows verbatim path form: \\?\<repo-path>

User-visible behavior

• The <project-name> project should have 19 active chats.
• Codex Desktop sidebar shows only 15 visible chats.
• Four expected active chats are not visible in the project sidebar:
• <thread-id-1> — <milestone-or-thread-title-1>
• <thread-id-2> — <milestone-or-thread-title-2>
• <thread-id-3> — <milestone-or-thread-title-3>
• <thread-id-4> — <milestone-or-thread-title-4>
• Ctrl+G / thread search can find some content from the missing chats, but clicking the result does not open the conversation correctly.
• Running codex://threads/<thread-id> opens Codex Desktop, but the main chat area remains stuck on the blank Codex icon/loading state.
• codex resume <thread-id> works in Codex CLI for the affected threads.

Local state evidence

I inspected local Codex state before and after a narrow repair attempt.

SQLite / project count

state_5.sqlite shows:

• total <project-name> rows: 20
• active rows: 19
• archived rows: 1
• expected active chats excluding exit: 19

SQLite integrity checks passed:

PRAGMA integrity_check:
ok

PRAGMA quick_check:
ok

Title repair attempted

Initially, 8 active <project-name> rows had blank state_5.sqlite.threads.title values. I repaired only the blank SQLite titles using existing names from session_index.jsonl.

After repair:

active rows: 19
active blank titles: 0

This did not fix the Desktop UI. The sidebar still showed 15 chats and the same 4 deep links still opened to a blank Codex icon/loading view.

session_index.jsonl

session_index.jsonl contains the affected thread IDs and thread names. Sanitized examples:

{"id":"<thread-id-1>","thread_name":"<thread-title-1>","updated_at":"<timestamp>"}
{"id":"<thread-id-2>","thread_name":"<thread-title-2>","updated_at":"<timestamp>"}
{"id":"<thread-id-3>","thread_name":"<thread-title-3>","updated_at":"<timestamp>"}
{"id":"<thread-id-4>","thread_name":"<thread-title-4>","updated_at":"<timestamp>"}

Rollout JSONL parseability

The affected rollout JSONL files exist and parse with no errors:

<thread-id-1>
rollout exists: True
jsonl lines: 1039
parse errors: 0
record types: session_meta=1, event_msg=334, response_item=700, turn_context=3, compacted=1

<thread-id-2>
rollout exists: True
jsonl lines: 948
parse errors: 0
record types: session_meta=1, event_msg=323, response_item=620, turn_context=3, compacted=1

<thread-id-3>
rollout exists: True
jsonl lines: 556
parse errors: 0
record types: session_meta=1, event_msg=163, response_item=390, turn_context=2

<thread-id-4>
rollout exists: True
jsonl lines: 1016
parse errors: 0
record types: session_meta=1, event_msg=366, response_item=645, turn_context=3, compacted=1

.codex-global-state.json

.codex-global-state.json contains all affected thread IDs and contains these keywords:

<project-name>: FOUND
<project-parent-or-workspace-keyword>: FOUND
workspace-root: FOUND
workspace: FOUND
thread: FOUND
thread-workspace-root: NOT FOUND

The affected IDs are found in .codex-global-state.json.

process_manager reset attempted

The full log search showed at least one affected thread referenced in:

<user-home>\.codex\process_manager\chat_processes.json

I closed all Codex processes and renamed chat_processes.json to a .bak-* file so Codex would recreate process-manager state.

After reopening Codex Desktop:

• sidebar still showed 15 chats instead of 19
• codex://threads/<thread-id> still opened a blank Codex-icon loading view

Commands that reproduce the blank deep-link behavior

Start-Process "codex://threads/<thread-id-1>"
Start-Process "codex://threads/<thread-id-2>"
Start-Process "codex://threads/<thread-id-3>"
Start-Process "codex://threads/<thread-id-4>"

Each opens Codex Desktop but remains stuck on the blank Codex icon/loading state.

Expected behavior

If a thread is:

• present in state_5.sqlite
• archived = 0
• has a nonblank title
• has a valid rollout_path
• has a rollout JSONL file that exists and parses with zero errors
• is present in session_index.jsonl
• is present in .codex-global-state.json
• can be resumed with codex resume <thread-id>

then Codex Desktop should either:

1. show the thread under the correct project sidebar entry; and
2. render the conversation when opened through codex://threads/<thread-id> or thread search.

At minimum, Desktop should provide a supported local reindex/repair command that reconciles:

• state_5.sqlite
• session_index.jsonl
• .codex-global-state.json
• sessions/**/*.jsonl
• project/workspace root mappings

Actual behavior

Codex Desktop continues to show only 15 of 19 active project threads, and the 4 missing threads open to a blank/loading chat view via deep link, despite all local durable state being present and parseable.

Suspected area

This looks like a Desktop UI/sidebar/hydration issue rather than lost session data.

Possible areas:

• Desktop renderer/thread hydration path
• project/sidebar cache
• workspace/project grouping state
• thread-workspace-root-hints or equivalent project-thread mapping
• Windows path normalization between <repo-path> and \\?\<repo-path>
• stale Electron/UI cache not rebuilding from durable local state

Impact

This makes it look like project history is missing even though the local data still exists and can be resumed through the CLI. For multi-milestone project work, the missing threads contain build history, implementation context, review evidence, and milestone decisions that are difficult to reconstruct from the GUI.

Related issues

• #25463 — closest match: project threads disappear while JSONL/SQLite remain readable.
• #20493 — related blank codex://threads/<id> behavior despite parseable local transcript.
• #22796 — related Windows project sidebar / missing workspace-thread hint behavior.
• #19873 — related Windows project grouping/sidebar state drift.

I’m seeing what looks like the same issue on macOS.

Codex Desktop search finds the older thread, but when I click the result or press Enter, the main pane goes blank and stays on the Codex loading icon. The thread data appears to exist: the local log shows thread/search succeeding, and the selected conversation route changes to the expected /local/<thread-id> path. But after selecting the result, the app does not appear to resume/render the thread.

Environment:

• Codex Desktop: 26.602.40724
• Bundle version: 3593
• macOS
• Observed: 2026-06-05 around 4:29pm ET

Example log lines:

• 2026-06-05T20:29:31Z: thread/search succeeds.
• 2026-06-05T20:29:35Z: app routes to /local/019e8db6-cf73-7b72-8175-29e7b12dcdac.
• After that, the UI remains stuck on the blank loading view.

Expected: selecting a search result opens the thread.
Actual: selecting the result opens a blank loading pane.

Additional sanitized macOS reproduction: active project thread looked missing because discoverability/indexing was stale

I hit a closely related Codex Desktop case on macOS where the conversation data was not lost, but the UI made the thread look missing. This comment is intentionally sanitized: no project names, local paths, thread ids, screenshots, or conversation content.

Environment:

• Product: Codex Desktop
• Platform: macOS / Darwin 25.5.0 arm64
• Codex Desktop version: 26.602.40724
• Bundle version: 3593
• Observed: 2026-06-06 local time

User-visible behavior:

• A long-running project thread appeared to have disappeared after the conversation moved from the original topic into a later operational/debugging topic.
• Searching by the recent topic terms did not surface the thread.
• Checking archives also did not surface it, because it was not archived.
• The thread was ultimately visible only under an older/stale title in the project sidebar. The sidebar title/preview still reflected the original topic, not the latest work, so the user reasonably interpreted it as missing.

Evidence that the data was not lost:

• The thread was still present as an active, unarchived project thread.
• Agent-side thread inspection could list/read it directly and showed the latest turn had completed normally.
• There was no indication that the conversation content had been deleted; the issue was discoverability/search/sidebar metadata.

Expected behavior:

• Project thread search should find a thread by recent user/assistant message content, not only by stale title/early preview metadata.
• The project sidebar should refresh title/preview/recency enough that a thread whose topic has shifted remains identifiable.
• Archive views/search should make it clear when a thread is active/unarchived rather than simply absent.
• A user-facing reindex/repair command would help when sidebar/search state drifts from durable session state.

Actual behavior:

• The thread remained recoverable but was effectively hidden unless the user knew or guessed the old title.
• This created the impression of conversation loss and led to duplicate investigation work.

This seems to be the same general class as this issue, with a slightly different failure mode: not necessarily a blank deep link, but stale project/sidebar/search metadata making an active thread undiscoverable by the terms a user would naturally search for.

Hi everyone, I'm tracking the same Codex Desktop missing-thread/sidebar-history issue on macOS.

For those affected here: did you eventually get all hidden project threads back in Desktop? If yes, what exact method worked durably for you?

Examples I'm trying to distinguish:

• official update fixed it
• restart/reindex fixed it
• codex resume --all <thread-id> rehydrated it
• repairing session_index.jsonl / state_5.sqlite / .codex-global-state.json fixed it
• Codex Wake or another local recovery helper fixed it
• app bundle / listAllThreads patch fixed it
• nothing worked yet

In my case, the missing project threads still exist in ~/.codex/sessions and state_5.sqlite, but Desktop does not hydrate them back into the project sidebar after restart. Any confirmed durable fix would help. Please do not share private session contents; sanitized method/results are enough.

For those affected here: did you eventually get all hidden project threads back in Desktop? If yes, what exact method worked durably for you?

I opened up another chat and asked it to find it and refresh it, and that brought it up again.

For local session inspection/backup, Clean My Agent may help here; it reads Codex session data and can export sessions safely: https://github.com/blain3white/clean-my-agent

Adding a macOS datapoint after updating to the latest Desktop build.

Environment:

• macOS 15.5 (24F74)
• Apple Silicon / arm64
• Codex Desktop: 26.608.12217
• CFBundleVersion: 3722
• Local storage: default ~/.codex

Recovery status on my affected project:

• The update appears to have restored some previously missing threads.
• It did not restore everything.
• Older project threads are still missing from the Desktop sidebar/project history.
• The local data still appears to exist. For the affected project, state_5.sqlite still has 251 active/non-archived rows with the expected project cwd.
• Earlier checks also confirmed matching rollout JSONL/session files under ~/.codex/sessions.

So my current result is: 26.608.12217 looks like a partial recovery, not a full recovery. I still see this as an incomplete Desktop sidebar/project-history hydration issue rather than deleted local data.

Update: appears fixed after Codex Desktop 26.608.12217

Quick update from my Windows reproduction above: after updating Codex Desktop from 26.527.31326 to:

Codex Desktop 26.608.12217
Released Jun 9, 2026

the previously missing project conversations appear to have been restored in the Desktop UI.

Before update

In 26.527.31326, the affected project had:

• 19 expected active local project chats in state\_5.sqlite
• only 15 visible chats in the Codex Desktop project sidebar
• valid, unarchived SQLite rows for the missing chats
• nonblank repaired SQLite titles
• valid session\_index.jsonl entries
• rollout JSONL files present and parseable with parse errors: 0
• .codex-global-state.json containing the affected thread IDs
• codex resume <thread-id> working from CLI

But the Desktop UI still did not show four project chats, and opening them via:

Start-Process "codex://threads/<thread-id>"

resulted in a blank Codex-icon loading view.

After update

After updating to 26.608.12217, the missing conversations are visible again in the Codex Desktop project history. The restored threads include the previously missing milestone/project chats that had been recoverable only through local state or CLI resume.

Notes

I did not need to delete the canonical .codex session data. The data had remained present locally throughout the issue. The update appears to have fixed or repaired the Desktop UI/project-history hydration/listing behavior.

This suggests the issue was likely in the Desktop app's project/sidebar/thread hydration or local index reconciliation path rather than actual session data loss.

Thanks from my side this appears resolved in 26.608.12217, though it may still be useful to keep this issue open until maintainers confirm whether the fix was intentional and whether a local "reindex conversations" command is planned for similar future drift.

Wanted to add in something anecdotal that I've noticed - when a chat is pinned, it does not disappear.

I know this because oftentimes I have had chats that have disappeared, and then I've found them and got them to be surfaced again by pinning them. I'll continue chatting in the thread and unpin it, and then it will disappear again.

However, if I keep it pinned the entire time and use it and chat with it that way, it does not disappear.

I am seeing the same class of issue in Codex Desktop on macOS.

Feedback / thread id:

019eb41f-fec5-7621-a703-0ad135601ffc

Additional local evidence from my machine:

Saved project shown in Desktop sidebar:
/Users/max/Desktop/Activities/Pioneer

That path is a symlink to:
/Users/max/Desktop/Activities/summer program

readlink /Users/max/Desktop/Activities/Pioneer
=> /Users/max/Desktop/Activities/summer program

The user-visible problem is that after refreshing Codex Desktop or quitting/reopening it, the Pioneer project's chat history disappears from the project sidebar. The threads are not actually deleted: they can still be found through global search / direct thread access.

Local state confirms this is not data loss:

~/.codex/state_5.sqlite has 12 related thread rows with cwd:
/Users/max/Desktop/Activities/summer program

At the same time, the Desktop global project state keeps the saved workspace root as the symlink path:

electron-saved-workspace-roots = /Users/max/Desktop/Activities/Pioneer
project-order = /Users/max/Desktop/Activities/Pioneer
active-workspace-roots = /Users/max/Desktop/Activities/Pioneer

So this looks like a project/sidebar grouping bug where Codex Desktop mixes the saved symlink path with the resolved realpath. The underlying thread rows exist and are unarchived, but the project sidebar can look empty after refresh/restart.

Expected behavior: Codex Desktop should treat a saved project symlink path and its resolved realpath as the same project identity, or otherwise keep project/thread grouping stable across restarts. At minimum, it should provide a safe reindex/repair path so existing local threads do not look deleted.

Adding another macOS datapoint that matches this issue, with local state still present but Desktop project/sidebar discovery incomplete after an update.

Environment

• Codex Desktop: 26.608.12217
• App build: 3722
• Bundled Codex CLI: 0.138.0-alpha.7
• Homebrew Codex CLI also installed: 0.137.0
• macOS local state directory: ~/.codex

User-visible symptoms

• After update, several projects show No chats / 暂无对话 in the left sidebar even though local threads still exist.
• Affected examples:
• FastAPI20251222: sidebar shows no chats, local DB has hundreds of active rows.
• Hermes: sidebar shows no chats, local DB has active rows.
• yousenwebview: sidebar shows no chats, local DB has active rows.
• deeptutor: sidebar shows only a partial recent subset rather than the full local history.
• Pinning individual threads makes some of them visible, but does not restore project-level history.
• A full Cmd+Q quit/reopen did not fix it.

Local evidence

SQLite integrity checks pass:

state_5.sqlite PRAGMA integrity_check: ok
logs_2.sqlite PRAGMA integrity_check: ok

Thread counts from ~/.codex/state_5.sqlite:

total threads: 1781
active/non-archived threads: 1641
active threads whose cwd contains deeptutor: 1173
active threads whose cwd contains yousenwebview: 48
active threads whose cwd contains Hermes: 3
active threads whose cwd contains FastAPI20251222: 405

Largest affected active cwd groups:

/Users/<user>/Developer/CYH_2/Markzuo/deeptutor: 1007
/Users/<user>/Documents/CYH_2/Markzuo/FastAPI20251222: 403
/Users/<user>/Developer/CYH_2/Markzuo/deeptutor/yousenwebview: 48
/Users/<user>/Documents/CYH_2/Hermes: 3

There is also a symlink/realpath split for one project:

/Users/<user>/Documents/CYH_2/Markzuo/deeptutor
-> /Users/<user>/Developer/CYH_2/Markzuo/deeptutor

The Git worktree authority resolves to:

/Users/<user>/Developer/CYH_2/Markzuo/deeptutor

Recovery attempts already tried

1. Verified state_5.sqlite and logs_2.sqlite are intact.
2. Verified affected rows are archived=0 and have valid cwd, titles, and rollout paths.
3. Pinned several important missing threads. This helped access individual threads but did not repair project grouping.
4. Checked archived state; affected threads were not archived.
5. Backup-first edit of ~/.codex/.codex-global-state.json:

• expanded thread-workspace-root-hints from about 81 to about 1700;
• added missing project roots to project-order;
• added both symlink and realpath roots for deeptutor and yousenwebview.

1. Fully quit Desktop with Cmd+Q and reopened.

Result: project/sidebar history is still incomplete. This suggests .codex-global-state.json hints/project-order are not sufficient, or another renderer/app-server/sidebar cache or query layer is involved.

Related but probably separate observation

The same update window also left mobile Remote Control unusable locally. Evidence points to standalone/daemon drift rather than the same sidebar root cause:

• old codex remote-control process was still from Homebrew Codex;
• bundled Desktop codex remote-control start --json failed because managed standalone Codex was missing at ~/.codex/packages/standalone/current/codex;
• existing remote_control_enrollments entries were stale.

Ask

Could the Desktop team provide a supported local reindex/rebuild procedure for project history discovery?

In particular:

1. What is the authoritative source for project/sidebar history: state_5.sqlite, session_index.jsonl, .codex-global-state.json, cloud sync, an app-server cache, or a combination?
2. Should Desktop project grouping canonicalize symlink paths and realpaths before matching threads.cwd?
3. Why can pinned/restored threads appear while the project view still shows No chats?
4. Is there a supported “All local threads” recovery view independent of project grouping and recent-window limits?

I have not attached raw DB/log/session files because they can contain private prompts, paths, git remotes, tokens, cookies, and API keys. Happy to provide more sanitized diagnostics if there is a recommended redaction script.

Adding a current-build macOS datapoint and linking the broader report: #27601.

Environment:

Codex Desktop 26.608.12217 / build 3722
macOS 26.3 / Darwin 25.3.0 arm64

Local data was intact:

sqlite integrity: ok
state_5.sqlite thread count: 5131
unarchived thread count: 2690
session_index.jsonl rows: 5131

After a restart/account-switching session, .codex-global-state.json had drifted active-workspace-roots to a single child workspace. That made other workspace histories appear missing/unloaded even though the DB and session index were healthy. Reopening Desktop against the parent workspace root restored the active root without killing active workers:

/Applications/Codex.app/Contents/Resources/codex app <parent-workspace-root>

One detail that may help triage: a state repair while Desktop was live could be overwritten back to a child root by the running app. Reopening the parent root through the bundled launcher made the repair stick.

Additional macOS reproduction: active task hidden after blank view and Back navigation

I hit what appears to be the same Codex Desktop project/thread visibility bug on macOS.

Environment

• Codex Desktop: 26.707.51957 (build 5175)
• macOS: 26.1
• Architecture: arm64
• Observed: 2026-07-15

User-visible behavior

1. A long-running local task was active inside a saved project.
2. The task view went blank. The user reported this had started recurring after a recent app update.
3. Pressing Back returned to the project's empty landing page, showing the new-task composer but no visible active task/history.
4. This made the active task appear to have disappeared or been deleted.

Evidence that the task was not lost

• The task was still returned by the local thread-listing API.
• Its status was still active, with an in-progress turn and intact recent history.
• Navigating directly to the recovered thread ID succeeded immediately and restored the task view.
• No session repair, database edit, app restart, or repository change was required.

This points to a Desktop project-list/navigation/rendering inconsistency rather than deleted task data.

Expected behavior

• If an active task view goes blank, Back should return to a project page that still lists the active task.
• An active task must remain discoverable from the project page and global task search.
• The UI should offer a reload/recovery state instead of presenting an apparently empty project.

Impact

For long-running work this looks like data loss and can lead users to start duplicate tasks or lose confidence that active work is still running.

Private project names, local paths, and thread IDs are intentionally omitted.

Recovery experience and real-work impact

One detail that made the impact concrete: the hidden task was part of a long-running catalogue and approval workflow for Mean Man, a New Zealand grocery price-comparison app. The task held ongoing crawler, admin-review, and verification context, so the empty project screen looked like substantial active work had vanished.

The recovery itself was a useful Codex dogfooding case:

1. I noticed the task view had gone blank and that Back returned me to an apparently empty project.
2. I asked Codex, from a new task in the same project, to find where the active work had gone.
3. Codex queried its local task list, identified the intended task as still active and in progress, inspected its recent state, and navigated the desktop app directly back to that task.
4. The original task reopened successfully with its working context intact.

We recovered it collaboratively using Codex itself, without restarting the app, altering local databases, repairing indexes, or reconstructing the work from a handoff. That was reassuring, but users should not need a second Codex task to discover and reopen an active task hidden by the Desktop UI.

This should probably be treated as an index/projection consistency issue, not as conversation deletion.

For recovery, I would separate three states: durable thread record exists, project association exists, and UI/search projection has indexed it. The UI can then show “local thread exists but project index is stale” with a rebuild action instead of rendering an empty project. The important invariant is that a missing projection must not look identical to an empty project.

I maintain Better Agent (https://github.com/ofekron/better-agent), and this same separation matters for restart recovery: session JSON/events are the source, while sidebar/search/project views are rebuildable projections. If useful, a star helps other agent-runtime builders find the project.