Desktop thread panel hides existing workspace threads after workspace restructuring; backend pagination still returns them

Summary

This is a desktop app thread-visibility bug, not thread data loss.

On this machine, many historical threads for the New project workspace still exist locally and are still returned by thread/list when pagination is followed, but the desktop thread panel does not show them reliably for the current project/workspace view.

The strongest evidence points to one or both of these failure modes:

1. the desktop UI is not consuming all thread/list pages
2. the desktop UI is matching workspaces by overly strict raw cwd string equality after workspace restructuring/path drift

Environment

• Codex Desktop session metadata reports cliVersion: 0.118.0-alpha.2
• macOS 26.4.0
• workspace root: /Users/leon/Library/CloudStorage/OneDrive-个人/Codex/New project
• storage context includes OneDrive-backed paths and later workspace restructuring into Projects/...

What I am seeing

In the desktop app, many threads that definitely belong to this Codex workspace no longer appear in the thread panel.

This is especially visible in the Codex Project / New project workspace family:

• there are many historical threads for the workspace
• the user can no longer see large parts of them in the desktop panel
• some subproject views appear much thinner than the actual thread history would suggest

However, direct backend inspection shows the threads still exist.

Backend evidence

1. Paginated thread/list returns far more threads than a single page

Using codex app-server on 2026-04-06, I paged through default thread/list results from the workspace root:

• total interactive threads collected across pagination: 277
• total pages returned: 6
• threads whose cwd is exactly /Users/leon/Library/CloudStorage/OneDrive-个人/Codex/New project: 87

But if I only inspect the first page:

• limit=50 first page contains only 18 threads for that same root workspace

So if the desktop panel is only using the first page, or filtering after fetching only one page, it will hide a large fraction of real workspace history.

2. Historical thread cwd values are split across old and new path shapes

Scanning local session metadata under ~/.codex/sessions/... shows:

• /Users/leon/Library/CloudStorage/OneDrive-个人/Codex/New project -> 69 sessions
• /Users/leon/Library/CloudStorage/OneDrive-个人/Codex/New project/codex-mobile-mirror -> 3 sessions
• /Users/leon/Library/CloudStorage/OneDrive-个人/Codex/New project/Projects/codex-mobile-mirror -> 0 sessions

That means the current project structure and the historical thread metadata are no longer aligned to one exact cwd string.

If the desktop panel groups or filters by exact raw cwd equality rather than a normalized workspace-root relationship, historical threads can appear to "disappear" even though the local thread/session data is still present.

Steps to reproduce

1. Have a macOS Codex Desktop workspace with substantial thread history.
2. Use the workspace over time from the root path, creating many threads.
3. Later restructure the workspace so active work happens under subdirectories such as Projects/....
4. Reopen and continue using the workspace in Codex Desktop.
5. Observe that the desktop thread panel does not show the full historical thread set for the project/workspace.
6. Compare with direct backend inspection:

• run codex app-server
• call paginated thread/list
• compare first-page results with full paginated results
• compare returned cwd values with current workspace/subproject paths

Expected behavior

The desktop app should not hide valid historical threads merely because:

• they fall on later thread/list pages
• the workspace now opens from a slightly different but related path shape
• the project was reorganized under a new subdirectory structure

At minimum:

• the desktop thread panel should consume the full paginated result set relevant to the workspace view
• workspace matching should be more robust than exact raw cwd equality
• thread history should remain visible after reasonable project reorganization within the same workspace

Why I think this is a desktop visibility bug

The important point is that the threads are still there:

• session files still exist under ~/.codex/sessions/...
• thread/list still returns them when pagination is followed
• this does not look like thread deletion or corruption

So the failure appears to be in desktop-side listing, filtering, or grouping logic.

Possibly related issues

• #15347 Support moving/remapping a workspace folder without losing thread history
• #15448 Codex App hides existing threads when a project is reopened via a symlinked workspace path on macOS
• #16545 thread/list filesystem fallback can hide older matching threads after hitting 10,000-file scan cap

This report is not identical to those:

• it is not only about symlinks
• it is not only about moved drives
• it is not only about the 10,000-file fallback cap

The current evidence suggests a desktop-panel visibility failure that can be triggered by pagination incompleteness and/or overly strict workspace path matching after restructuring.

Local references

• [/Users/leon/Library/CloudStorage/OneDrive-个人/Codex/New project/Projects/codex-mobile-mirror/docs/DECISION_LOG.md](/Users/leon/Library/CloudStorage/OneDrive-个人/Codex/New%20project/Projects/codex-mobile-mirror/docs/DECISION_LOG.md)
• [/Users/leon/Library/CloudStorage/OneDrive-个人/Codex/New project/Projects/codex-mobile-mirror/notes/spikes/app_server_thread_visibility_spike_20260402-205636.json](/Users/leon/Library/CloudStorage/OneDrive-个人/Codex/New%20project/Projects/codex-mobile-mirror/notes/spikes/app_server_thread_visibility_spike_20260402-205636.json)