What version of Codex is running?
Codex Mac app 26.325.31654 (1272)
CLI on this machine is also:
codex-cli 0.118.0-alpha.2
What subscription do you have?
Pro
Which model were you using?
Not obviously model-specific. The issue is with the Mac app thread list itself.
What platform is your computer?
Darwin 25.3.0 arm64
What issue are you seeing?
The Codex Mac app stops showing my local threads and eventually reports effectively "no threads", even though the local thread data is still present on disk and in the local SQLite database.
This is not limited to one repository. It affects threads across many local repos.
I verified locally that the underlying data still exists:
~/.codex/state_5.sqlite still contains 1176 threads, with 1170 unarchived
- the corresponding rollout files are still present under
~/.codex/sessions
- specific missing threads can still be found locally
So the problem appears to be the Mac app's thread enumeration / sidebar listing path, not actual deletion of local thread data.
What steps can reproduce the bug?
I do not have a minimal clean repro yet, but this is the observed failure mode on my machine:
- Use the Codex Mac app across multiple local repositories.
- Accumulate many local threads over time.
- Open the Mac app later and find that the sidebar no longer shows the local threads, even though they still exist in:
~/.codex/state_5.sqlite
~/.codex/sessions/...
- Restarting the app does not restore them.
I also tried several recovery steps locally and none fixed the issue:
- Rebuild the local thread index by removing
~/.codex/session_index.jsonl and ~/.codex/state_5.sqlite*
- Clear Codex app
Local Storage and Session Storage
- Force local mode by setting:
codexCloudAccess = disabled
environment = null
selected-remote-host-id = null
- Normalize thread titles in SQLite and recreate
session_index.jsonl
- Rewrite thread
updated_at values and rebuild the index again
After all of that, the Mac app still did not repopulate the local thread list.
What is the expected behavior?
The Mac app should enumerate and show my existing unarchived local threads from the local Codex store instead of showing an empty or missing thread list.
If the local database and rollout files are intact, the sidebar should be able to recover from cache/index corruption and display those threads again.
Additional information
Relevant local evidence from this machine:
~/.codex/state_5.sqlite rebuilds successfully and still contains:
- 1176 total threads
- 1170 unarchived threads
- many recent active threads still exist locally, so this is not just stale historical data
- the missing threads are still present in rollout JSONL files under
~/.codex/sessions
- one confirmed example is a previously missing thread that exists both in SQLite and in its rollout file
- after normalizing titles, there were no excessively long or multiline titles left in the DB, but the sidebar was still empty
- the app repeatedly restored a cloud environment / remote-host selection even after I cleared those values from local state
- fresh startup logs did not appear to request a normal
thread/list flow; they showed thread/resume for the current session but not a full local thread listing pass
This looks like a Mac app bug in local thread discovery / sidebar rendering rather than actual thread loss.
What version of Codex is running?
Codex Mac app 26.325.31654 (1272)
CLI on this machine is also:
codex-cli 0.118.0-alpha.2
What subscription do you have?
Pro
Which model were you using?
Not obviously model-specific. The issue is with the Mac app thread list itself.
What platform is your computer?
Darwin 25.3.0 arm64
What issue are you seeing?
The Codex Mac app stops showing my local threads and eventually reports effectively "no threads", even though the local thread data is still present on disk and in the local SQLite database.
This is not limited to one repository. It affects threads across many local repos.
I verified locally that the underlying data still exists:
~/.codex/state_5.sqlitestill contains 1176 threads, with 1170 unarchived~/.codex/sessionsSo the problem appears to be the Mac app's thread enumeration / sidebar listing path, not actual deletion of local thread data.
What steps can reproduce the bug?
I do not have a minimal clean repro yet, but this is the observed failure mode on my machine:
~/.codex/state_5.sqlite~/.codex/sessions/...I also tried several recovery steps locally and none fixed the issue:
~/.codex/session_index.jsonland~/.codex/state_5.sqlite*Local StorageandSession StoragecodexCloudAccess = disabledenvironment = nullselected-remote-host-id = nullsession_index.jsonlupdated_atvalues and rebuild the index againAfter all of that, the Mac app still did not repopulate the local thread list.
What is the expected behavior?
The Mac app should enumerate and show my existing unarchived local threads from the local Codex store instead of showing an empty or missing thread list.
If the local database and rollout files are intact, the sidebar should be able to recover from cache/index corruption and display those threads again.
Additional information
Relevant local evidence from this machine:
~/.codex/state_5.sqliterebuilds successfully and still contains:~/.codex/sessionsthread/listflow; they showedthread/resumefor the current session but not a full local thread listing passThis looks like a Mac app bug in local thread discovery / sidebar rendering rather than actual thread loss.