Desktop-resumed exec thread disappears from history after navigating away

What version of the Codex App are you using?

Codex Desktop 26.825.51511 (build 7377).

The affected thread was created with codex-cli 0.151.0; the currently installed CLI is codex-cli 0.152.0.

What subscription do you have?

ChatGPT account with Codex access.

What platform is your computer?

macOS 14.4.1 (Apple Silicon / arm64).

What issue are you seeing?

A persisted thread originally created by codex exec can be opened/resumed in Codex Desktop and used as an ordinary interactive chat, but it disappears from Desktop sidebar/search after navigating away.

This is more than the known behavior where untouched exec sessions are intentionally not enumerated. In this case Desktop had adopted the thread in practice:

• Desktop successfully called thread/read and thread/resume for it.
• The user continued the conversation in Desktop across 10 completed user turns over two days.
• New turns completed normally and the rollout continued updating.
• After the user navigated to another thread, the resumed thread was no longer discoverable in Desktop.

The thread was not deleted or archived:

• state_5.sqlite still contains the thread with archived = 0 and archived_at IS NULL.
• Its rollout JSONL still exists and parses (about 32 MB / 3,735 records).
• App logs contain no archive or delete event for it.
• Direct thread/read / thread/resume by ID succeeds.

Sanitized metadata for the affected thread:

• source = exec
• session originator: codex_exec
• history mode: paginated
• cwd: an existing local Git worktree
• project ID: empty
• Desktop sidebar mode: grouped by project

The likely failure is that source remains exec even after Desktop resumes the thread and accepts interactive turns, so normal source/project enumeration filters continue to hide it as soon as the direct view is left.

Observed sequence / likely reproduction

1. Create a persisted codex exec session in a local Git worktree.
2. Open or resume that thread in Codex Desktop by thread ID/deep link.
3. Continue it interactively in Desktop and let several turns complete.
4. Navigate to another Desktop thread.
5. Search the sidebar/history for the resumed thread.
6. Observe that it is absent even though direct read/resume by ID still works and the local state row is unarchived.

What is the expected behavior?

Once Desktop explicitly resumes an exec-origin thread and accepts interactive user turns, it should remain discoverable in Desktop history.

Possible fixes include:

• promote/adopt the thread into a Desktop-enumerated source after the first interactive Desktop turn;
• record a separate durable adoptedByInteractiveClient visibility flag;
• expose a Desktop equivalent of the CLI's “include non-interactive sessions” filter; or
• at minimum warn before allowing interactive work in a thread that will disappear from normal discovery after navigation.

An active thread targeted by a scheduled automation should also not become undiscoverable from the supervision UI.

Related issues

• #16385 documents that untouched exec sessions are intentionally not enumerated.
• #32614 covers agent-created durable top-level exec tasks hidden from Desktop/mobile discovery.
• #36135 covers the same missing “include non-interactive” affordance in the VS Code extension.
• #27159 is the broader Desktop symptom where intact, unarchived threads disappear from sidebar/search.

The lifecycle transition here is the narrower bug: Desktop can resume the hidden-source thread, accept substantial interactive work in it, and then make that same active conversation undiscoverable after navigation.

Private thread ID, local path, repository name, title, prompts, and logs are intentionally omitted, but can be supplied privately if maintainers need them.

Start by tracing Desktop history/sidebar enumeration and the thread/read and thread/resume lifecycle for threads whose source is exec. Inspect the unarchived state row in state_5.sqlite and the related rollout metadata, then reproduce the navigation sequence. Done means a resumed exec-origin thread with completed interactive turns remains discoverable after navigating away, without changing untouched exec-session behavior.