Codex Desktop hides existing workspace threads on macOS

[mikebmod]

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

Version 26.305.950 (863)

What subscription do you have?

Enterprise

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Codex Desktop on macOS only shows 1 thread for workspace but the local store contains 16 threads for that exact cwd, 15 active.

What steps can reproduce the bug?

Verified locally:

• ~/.codex/state_5.sqlite has 16 rows for cwd=/path/to/project
• raw rollout files exist under ~/.codex/sessions and ~/.codex/archived_sessions
• cache reset did not fix it
• full state rebuild did not fix it
• reinstalling Codex Desktop did not fix it

What is the expected behavior?

No response

Additional information

No response

[github-actions]

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

• Codex desktop is showing stale/orphaned thread entries that cannot be reopened or archived. #14162
• Local Codex Desktop sessions disappear from sidebar after restart (Windows App) #13713
• Sidebar stuck on infinite loading spinner on macOS (app version 26.305.950) #13740

Powered by Codex Action

[bixinhaner]

I can reproduce the same bug on macOS: Codex App shows only a small subset of workspace threads, while local data is intact.

Date: 2026-03-12
Platform: macOS (Darwin arm64)
CLI version on this machine: codex-cli 0.111.0
Workspace: /Users/like/Desktop/ReportHub

What I see

In Codex App UI, this workspace only shows 3 threads.

But local sqlite has many more rows for the exact same cwd:

SELECT COUNT(*), MIN(datetime(created_at,'unixepoch','localtime')), MAX(datetime(created_at,'unixepoch','localtime'))
FROM threads
WHERE cwd='/Users/like/Desktop/ReportHub';
-- 67 | 2026-01-13 00:54:29 | 2026-03-09 20:14:44

SELECT source, COUNT(*)
FROM threads
WHERE cwd='/Users/like/Desktop/ReportHub'
GROUP BY source;
-- cli 59
-- vscode 7
-- exec 1

The visible count (3) even matches this subset query:

SELECT COUNT(*)
FROM threads
WHERE cwd='/Users/like/Desktop/ReportHub'
  AND source='vscode'
  AND created_at >= strftime('%s','2026-03-01');
-- 3
Important evidence: hidden threads are still resumable
Threads that do not appear in App sidebar can still be resumed via CLI:

019c863d-7fd6-79f1-af96-337b9e9466ce (vscode)
019c1228-21e2-7a53-b3b1-890a31e978b3 (cli)
codex resume <thread_id> -C /Users/like/Desktop/ReportHub loads them normally.

So this looks like a desktop listing/filtering bug, not data loss.

Already tried (no fix)
Rebuilt ~/.codex/state_5.sqlite from sessions.
Reset ~/.codex/.codex-global-state.json.
Forced local mode in global state:
codexCloudAccess = "disabled"
selected-remote-host-id = null
Restarted Codex App after each step.
No change in sidebar result.

Could you check what exact thread/list filters/params Desktop sends for workspace thread list in this scenario?

[talvinder]

I can reproduce this on the macOS desktop app and have a stronger signal for the failure mode.

App build on my machine:

• Codex app 26.311.21342 (CFBundleVersion 993)
• macOS Darwin arm64

What I found locally:

• Threads were still present in ~/.codex/state_5.sqlite
• The missing-sidebar behavior was not data loss
• The metadata being used for listing was pathological: many rows had threads.title = first_user_message
• Those title values were often the entire multiline opening prompt, not a short label
• Example malformed rows were 3548 and 3877 characters long
• While the app remained open, it continued inserting new rows with this same pattern

Representative sqlite evidence:

SELECT COUNT(*) AS total_threads,
       SUM(CASE WHEN title = first_user_message THEN 1 ELSE 0 END) AS title_eq_first_user_msg,
       MAX(LENGTH(title)) AS max_title_len
FROM threads;
-- total_threads=5083, title_eq_first_user_msg=43, max_title_len=3877

SELECT id, LENGTH(title) AS title_len,
       SUBSTR(REPLACE(title, char(10), ' '), 1, 120) AS title_preview
FROM threads
WHERE title = first_user_message
ORDER BY updated_at DESC
LIMIT 4;

Example previews from those malformed rows:

• You are the review and verification agent for Linear ticket \TAL-33` ... (3877` chars)
• You are the review and verification agent for Linear ticket \TAL-31` ... (3548` chars)

I manually normalized the stored titles to short single-line labels and rebuilt ~/.codex/session_index.jsonl; after that, the sidebar threads became visible again. But while the desktop app stayed open, it kept writing new bad rows.

So this looks less like a generic "thread list filter" bug and more like a desktop app write-path bug where new threads are persisted with title = first_user_message instead of a derived short title, which then breaks or degrades the sidebar listing path.

If useful, I can also provide the exact normalization query/script I used as a temporary local workaround.

[bixinhaner]

I have a stronger repro now. This does not look like data loss. It looks like the Desktop sidebar is effectively gated by local sqlite updated_at ordering/truncation.

Environment:

• Date: 2026-03-18
• Platform: macOS arm64
• Workspace: /Users/like/Desktop/Trae/ReportHub

Local sqlite state for this exact workspace:

SELECT COUNT(*), MIN(datetime(created_at,'unixepoch','localtime')), MAX(datetime(created_at,'unixepoch','localtime'))
FROM threads
WHERE cwd='/Users/like/Desktop/Trae/ReportHub';
-- 69 | 2026-01-13 00:54:29 | 2026-03-17 22:57:27

SELECT source, COUNT(*)
FROM threads
WHERE cwd='/Users/like/Desktop/Trae/ReportHub'
GROUP BY source;
-- cli 59
-- vscode 9
-- exec 1

SELECT archived, COUNT(*)
FROM threads
WHERE cwd='/Users/like/Desktop/Trae/ReportHub'
GROUP BY archived;
-- archived=0 for all 69 rows
The app only showed a few recent threads. I tested several hypotheses:

1. cli_version is NOT sufficient
I picked a hidden thread:

thread id: 019cbe98-1245-7122-aeb5-3f95b420403c
title: Is attaching files to emails still unavailable in the report writing function？
source: vscode
original cli_version: 0.107.0
I changed only:

rollout session_meta.payload.cli_version
sqlite threads.cli_version
from 0.107.0 to 0.115.0-alpha.27

Then I fully restarted Codex Desktop.

Result:

the thread still did not appear in the sidebar.
2. updated_at DOES affect visibility
I then restored cli_version and changed only sqlite threads.updated_at for the same hidden thread, pushing it to the newest row for that workspace:

UPDATE threads
SET updated_at = <latest timestamp>
WHERE id='019cbe98-1245-7122-aeb5-3f95b420403c';
After fully restarting Codex Desktop:

this previously hidden thread appeared in the ReportHub sidebar.
3. Important implication
This strongly suggests the Desktop sidebar is not enumerating all matching workspace threads.
It appears to be showing only a recent subset ordered by sqlite updated_at, or applying a truncation/pagination bug on top of that ordering.

This is not just “old sessions are unreadable”:

hidden threads still exist in sqlite
hidden threads are resumable by id
changing only sqlite updated_at makes a hidden thread visible
For comparison, changing rollout file mtime alone was not enough.

Can you check whether Desktop’s workspace thread list is:

applying an unintended hard limit,
failing to paginate past the first few rows,
or using a stale cursor/window over updated_at-sorted results?