Desktop sidebar does not live-register threads created by external app-server until restart

What version of the Codex App are you using?

ChatGPT/Codex Desktop 26.727.40816 (build 6067).

The external app-server was launched by codex-cli 0.146.0-alpha.9.2.

What platform is your computer?

macOS 26.5.2 (build 25F84), Apple Silicon / arm64.

Reproduced independently on two Macs running the same app and CLI versions.

What issue are you seeing?

Threads created successfully through a separate local codex app-server --stdio process are persisted and readable by exact thread ID, but a Codex Desktop instance already running on that same Mac does not add them to its visible project/sidebar catalog.

For every affected thread:

• thread/start returned one durable UUID;
• thread/name/set succeeded;
• turn/start completed successfully;
• exact Remote Control/list/read access returned the correct title, working directory, first prompt, completed initial turn, and no attention blocker;
• the task remained reported as notLoaded and was absent from the running Desktop sidebar.

After fully restarting ChatGPT/Codex Desktop on that host, all newly created threads appeared immediately with their correct titles and histories.

This reproduced as a batch of three threads on each of two different Macs (six threads total). Threads created through the Desktop app's ordinary local saved-project creation surface on a third Mac appeared immediately and did not require a restart.

Steps to reproduce

1. Keep ChatGPT/Codex Desktop running on macOS with an existing saved project.
2. Start a separate app-server process on the same host:

codex app-server --stdio

1. Perform the normal initialization handshake.
2. For a new thread:

• call thread/start with the saved project's working directory;
• call thread/name/set with a recognizable title;
• call turn/start with a short prompt;
• wait for the matching terminal turn/completed;
• close the external app-server session cleanly.

1. Confirm by exact thread ID that the thread is persisted and readable.
2. Observe that the already-running Desktop app does not show the thread in its project/sidebar task list.
3. Fully quit and reopen Desktop.
4. Observe that the thread now appears immediately.

The behavior reproduced for three sequential threads per peer host on two hosts.

Expected behavior

When a durable thread is created by another supported app-server process on the same host, a running Codex Desktop instance should refresh or invalidate its thread catalog and show the new thread within a bounded normal indexing interval.

At minimum, Desktop should have a supported host-addressable refresh mechanism so callers do not need to restart the entire app.

Actual behavior

The external creation RPCs and initial turn all succeed, and the thread is durably readable by ID, but the running Desktop renderer never displays it. The task becomes visible only after restarting Desktop.

Impact

This breaks observable multi-host/task initialization built on the documented app-server protocol. Automation can create fully functioning threads that remain invisible to the human operator, forcing a disruptive Desktop restart on every affected host after each creation batch.

Workaround

Fully restart ChatGPT/Codex Desktop on each host after external app-server thread creation. No macOS restart is required.

Additional information

This appears related to #32737, where backend-created fanout child threads are not registered in the Desktop renderer until restart. This report is narrower and independently reproducible without sub-agents or fanout: ordinary explicit thread/start calls from a separate app-server process produce the same missing live-catalog registration.

No task UUIDs, prompt contents, repository names, usernames, or private paths are included.