[Windows][Pet] Pet activity opens an unmaterialized realtime voice thread and shows "thread not found"

What version of the Codex App are you using?

• Codex Desktop package: 26.818.4152.0
• Bundled app-server: 0.149.0-alpha.4.1
• Platform: Windows x64
• Observed: 2026-08-25 17:34:04 CDT
• Feature involved: Codex Pet activity view and Realtime Voice

What issue are you seeing?

The Codex Pet activity view showed a task that was still running, but opening the activity view produced:

thread not found: <thread-id>

The visible running task was 继续研究 ("Continue research"). Local app-server logs show that this task was still sampling and running commands at the time of the screenshot. The error referred to a different conversation, a Realtime Voice Chat Fork.

I inspected the conversation referenced by the error. It was not a normal materialized thread:

• the app reports notLoaded;
• the thread has zero turns and no user event;
• tokens_used is zero;
• its rollout JSONL contains only session_meta, with no user, assistant, tool, or transcript records;
• the Realtime call was created successfully with HTTP 201, then closed before the first normal user turn was persisted.

The result is a stale, empty Voice placeholder that is still exposed to the Pet activity surface. Selecting it sends the placeholder ID through the normal local-thread navigation path, and the renderer then shows thread not found.

What steps can reproduce the bug?

The following sequence matches the captured state:

1. Start a new empty Realtime Voice Chat Fork on Windows.
2. End or interrupt it before the first text or voice user turn is persisted.
3. Leave the provisional conversation in the local conversation/activity state.
4. Wake the Codex Pet and open its activity view, or refresh the corresponding remote activity view.
5. Select the activity item for the empty Voice placeholder.
6. Observe a thread not found error instead of opening a valid conversation.

The exact final click source in this report is not identifiable from the local server logs, so I cannot distinguish the Windows Pet click from the phone/remote activity bridge. The invalid target state is independently confirmed in the local thread database, rollout, and app-server logs.

What is the expected behavior?

• An unmaterialized Realtime Voice placeholder should not be exposed as a normal Pet activity item.
• If Voice startup ends before the first user turn, the placeholder should be retired or hidden automatically.
• Selecting a Pet activity item should open the associated materialized conversation.
• Navigation should check that the target thread can be loaded before sending it to the normal local-thread route.
• A stale item should fail quietly or offer a cleanup action rather than showing a repeated thread not found toast.

What is the actual behavior?

The empty Voice placeholder remains eligible for Pet activity handling. The installed desktop bundle filters out conversations marked as threadSource=realtime_voice, but this affected row was persisted as thread_source=user. It therefore passed through the ordinary local-conversation path, which generated a /local/<thread-id> route.

The main-window handler validates the route shape but does not preflight whether the thread has a materialized rollout or readable turns. The app then reports thread not found.

This also makes the UI misleading: a separate task can continue running normally while the Pet surface reports an error for the stale Voice placeholder.

Additional information

I initially suspected #35746, but this failure occurs before paginated history is available. The affected rollout has no normal history records at all, so the direct failure is the unmaterialized Voice placeholder and its incorrect source classification, not a malformed paginated-history record.

Related reports:

• #37058, Windows empty Voice placeholder remains visible and reports no rollout found.
• #37612, Windows empty provisional Voice thread fails during Realtime startup.
• #35629, stale Voice thread reference produces thread not found.
• #38932, Pet activity navigation failure on macOS with valid target threads.

No raw local paths, transcript content, account information, full thread ID, or screenshot is attached. I can provide a redacted log excerpt if needed.