Desktop sidebar "No chats": thread/list returns 0 when cwd == $HOME (all builds)

Resolved 💬 2 comments Opened Jun 6, 2026 by FlareForward Closed Jun 6, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

In Codex desktop, thread/list filtered by a cwd equal to the user's home directory returns 0 threads, even though non-archived threads exist with exactly that cwd. Any non-home cwd returns its rows correctly. Because the desktop sidebar's default/active project is the home directory, it shows "No chats" (both the project list and the global "Chats" list) despite the threads existing. Cmd-K Search is unaffected (it doesn't filter by cwd), so all data remains reachable.

Affected builds

Reproduced identically on 26.601.20914, 26.601.21317, and 26.602.30954 — not a regression in any single build, and rolling back does not help. macOS.

Reproduce (codex app-server, v2 JSON-RPC over stdio)

initialize
thread/list { "limit": 300, "cwd": "/Users/me" }              -> 0      (home: empty)
thread/list { "limit": 300, "cwd": "/private/tmp" }           -> 4      (control, see below)
thread/list { "limit": 300, "cwd": "/Users/me/someproject" }  -> 43     (non-home works)
thread/list { "limit": 300, "cwd": "/Users/me/" }             -> 0      (not slash-normalization)
thread/list { "limit": 300 }                                  -> 100    (backend has the data)

Control that isolates the cause to the home path (not a source filter)

/private/tmp holds 9 non-archived threads — 4 source=vscode + 5 source=exec. thread/list(cwd=/private/tmp) returns 4 (the vscode threads; exec is filtered, which is expected). So vscode threads list normally for a non-home dir.

Yet cwd=$HOME returns 0 despite the home dir holding 25 non-archived source=vscode threads (+9 exec) in state_5.sqlite. The only difference between the working control and the failing home query is that the failing one's cwd is exactly the user's home directory.

Ground truth (state DB)

SELECT COUNT(*) FROM threads WHERE cwd='/Users/me' AND archived=0;  -- 239 (incl. 25 vscode + 9 exec listable)
SELECT COUNT(*) FROM threads WHERE cwd='/private/tmp' AND archived=0; -- 9 (4 vscode + 5 exec)

Ruled out (with evidence)

  • Build regression — reproduces on 20914 / 21317 / 30954 alike; rollback does nothing.
  • Data loss / mass-archive — all threads present; archived_at spread naturally over weeks, not clustered at any update.
  • NULL created_at_ms/updated_at_ms — 0 NULLs; backfill complete.
  • source / thread_source filter — the control proves vscode threads list for non-home dirs.
  • Slash normalization — $HOME and $HOME/ both return 0.
  • Stale process — confirmed after a clean full relaunch.

Likely area

thread/list's cwd matching appears to special-case or mishandle the home-directory path: exact-match on $HOME returns nothing while subdirectories of $HOME match correctly.

Impact / workarounds for users

  • Sidebar home project + global "Chats" show "No chats" despite many threads.
  • Workaround: use Cmd-K Search, or select a non-home project (those list fine). Rolling back builds does not help.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26647

Powered by Codex Action

FlareForward · 2 months ago

Resolved as of 26.602.40724 (newer than the three builds above). Re-ran the same app-server repro on the same machine / state_5.sqlite:

thread/list { limit:300, cwd:"$HOME" }    -> 2   (was 0; both now show in the home-project sidebar)
thread/list { limit:300, cwd:"/tmp" }     -> 4   (control, unchanged)
thread/list { limit:300 }                 -> 100 (unchanged)

The "No chats" symptom on the home project is gone.

One clarification so the counts line up: thread/list returns only threads with a non-empty first message/preview, for every cwd. Of the 35 non-archived source=vscode threads at $HOME, 33 are empty spawn shells (no first user message) and are correctly excluded; the 2 content-bearing ones are what now list and what the sidebar shows. So the listable set was always the content-bearing subset rather than the raw count cited above.

I can't directly A/B the prior build (every content-bearing home thread now present postdates the update), so reporting this as "no longer reproduces on 40724" rather than pinning a specific fix. Closing as resolved — happy to reopen if it recurs.