Desktop sidebar does not show local threads created through app-server

Summary

When a local thread is created through the app-server protocol, the thread is persisted and visible through thread/list, but Codex Desktop's sidebar does not show it.

This appears to be different from history/index corruption: in this case, the app-server can immediately list/read the newly-created thread, while the Desktop sidebar remains stale.

Reproduction

1. Start Codex Desktop.
2. Create a local thread through app-server thread/start.
3. Start the first turn through turn/start.
4. Call app-server thread/list.
5. Try opening the thread directly with codex://threads/<thread_id>.

Observed behavior

• thread/list returns the new thread.
• thread/read can read the thread.
• codex://threads/<thread_id> can open the thread.
• The Desktop sidebar does not show the new thread.
• Foregrounding Codex, opening the thread deep link, and reloading the window did not cause the sidebar to pick up the new thread.

Expected behavior

Desktop sidebar should eventually reflect local threads created through app-server, or the protocol should expose a supported way to notify Desktop that the thread list changed.

For integrations that create threads programmatically, a supported mechanism such as one of these would be useful:

• a thread/list/changed or thread/created notification;
• Desktop refetching thread/list when local app-server thread store changes;
• a documented method to invalidate/refetch the Desktop thread list.

Why this matters

External integrations can create valid local Codex threads through app-server, but users cannot see those threads in the Desktop sidebar unless the integration drives the Desktop UI to create the thread instead.

For now, the reliable workaround is to open codex://new?prompt=...&path=... and submit through the Desktop UI, but that is much less stable than a protocol-level synchronization path.

Environment

• Codex Desktop with bundled app-server
• macOS
• Local app-server protocol over stdio