Pinned/local Codex App threads cannot be opened despite valid local session files

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App 26.611.61049; bundled CLI reports codex-cli 0.140.0-alpha.19

What subscription do you have?

Enterprise

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

After a recent Codex App update, older pinned/local chats appear in the Codex App UI but cannot be opened. This looks like history loss in the app, but the underlying local data is still present on disk.

Observed from local state:

Pinned thread IDs in ~/.codex/.codex-global-state.json:

019ec803-70d9-7fb3-aadb-cec0436ddefc
019ec7e5-fe18-7920-b6da-16d5ec7dd6b0
019eba31-55d4-7580-8cda-5d2fed08b846
019e3e5f-e577-71e2-b0ba-403fb32b9c7a

App thread-read/open behavior:

019eba31-55d4-7580-8cda-5d2fed08b846 -> No Codex thread found
019ec7e5-fe18-7920-b6da-16d5ec7dd6b0 -> No Codex thread found
019ec803-70d9-7fb3-aadb-cec0436ddefc -> No Codex thread found
019e3e5f-e577-71e2-b0ba-403fb32b9c7a -> opens/readable

The broken threads are not deleted. They have rows in ~/.codex/state_5.sqlite, entries in ~/.codex/session_index.jsonl, and rollout JSONL files under ~/.codex/sessions.

Examples:

019eba31-55d4-7580-8cda-5d2fed08b846
source=vscode
thread_source=user
cli_version=0.140.0-alpha.2
archived=0
rollout_path=~/.codex/sessions/2026/06/12/rollout-2026-06-12T16-57-35-019eba31-55d4-7580-8cda-5d2fed08b846.jsonl

That JSONL exists and is readable. It contains session metadata, user message, final answer, and task-complete records. It is short, about 60 lines, but not empty/corrupt.

019ec7e5-fe18-7920-b6da-16d5ec7dd6b0
source=vscode
thread_source=user
cli_version=0.140.0-alpha.2
archived=0
rollout_path=~/.codex/sessions/2026/06/15/rollout-2026-06-15T08-49-59-019ec7e5-fe18-7920-b6da-16d5ec7dd6b0.jsonl

019ec803-70d9-7fb3-aadb-cec0436ddefc
source=cli
thread_source=user
cli_version=0.139.0
archived=0
rollout_path=~/.codex/sessions/2026/06/15/rollout-2026-06-15T09-22-09-019ec803-70d9-7fb3-aadb-cec0436ddefc.jsonl

The last one is a CLI-originated fork of 019e3e5f-e577-71e2-b0ba-403fb32b9c7a. The app can index/pin it, but cannot open it.

Related symptom: a heartbeat automation also failed because its target thread could not be loaded, even though the target thread has local session data:

automation id: premerge-davidk-fix-tests2-heartbeat
target_thread_id: 019ec983-1e38-75d1-926b-c985d247ab15
status: PAUSED

The automation failure reported that the thread had not been loaded yet / could not be loaded. This may be the same local thread hydration problem.

What steps can reproduce the bug?

1. Use Codex App with existing local history and pinned threads.
2. Update Codex App to 26.611.61049.
3. Open Codex App and try to open older pinned local threads.
4. Observe that several pinned threads fail to open / are reported as not found.
5. Verify local state on disk:

rg '<thread-id>' ~/.codex/.codex-global-state.json ~/.codex/session_index.jsonl
find ~/.codex/sessions -name '*<thread-id>*.jsonl'
sqlite3 'file:$HOME/.codex/state_5.sqlite?immutable=1' "SELECT id, archived, source, thread_source, cli_version, rollout_path FROM threads WHERE id='<thread-id>';"

1. The same IDs exist in the pinned list, session index, SQLite threads table, and rollout JSONL files, but Codex App still cannot open/read them.

A CLI workaround can resume at least some of the affected sessions:

/Applications/Codex.app/Contents/Resources/codex resume --all 019eba31-55d4-7580-8cda-5d2fed08b846

However, this may show only the preserved completed session content and does not repair Codex App visibility. Forking from CLI also does not appear to be a reliable repair path because a CLI-originated fork can be pinned/indexed by the app but still not openable.

What is the expected behavior?

Pinned local threads that have valid local backing data should open in Codex App.

At minimum, if Codex App cannot hydrate a local thread, it should show a specific repair/import/migration error instead of making the user think the chat history was deleted.

Expected behavior:

• If a thread ID is pinned, has a row in ~/.codex/state_5.sqlite, has an entry in ~/.codex/session_index.jsonl, and has a valid rollout JSONL under ~/.codex/sessions, the app should load/open it.
• CLI-originated/forked sessions should either be supported in the app or not be allowed to appear as normal pinned/openable app threads.
• Automations targeting an existing local thread should not fail with a generic not-loaded/not-found state when the backing thread data exists on disk.

Additional information

This is a high-impact local-history regression. From the user's perspective it looks like the Codex App lost chat history after an update, even though the JSONL data is still present.

Possible related bugs:

1. Pinned-thread state can reference local threads that the current app reader cannot hydrate.
2. The app thread loader/read API ignores or fails to import valid ~/.codex/sessions JSONL records even when state_5.sqlite has matching rows.
3. CLI-originated/forked sessions can be indexed/pinned by the app but are not reliably openable.
4. Automation heartbeat startup fails poorly when the target thread exists on disk but is not hydrated by the app.

Personal/user-impact note: Codex App has been updating itself roughly once a day, and over the last week the local-history/app reliability experience has felt like it is getting worse rather than better. This particular regression is especially frustrating because it makes preserved work look lost.