[Windows][26.814.5167.0] Hidden avatarOverlay owns completed thread; primary UI stays "Thinking"

What version of the Codex App are you using?

• ChatGPT/Codex Desktop for Windows: 26.814.5167.0
• Bundled Codex runtime: codex-cli 0.148.0-alpha.15

What platform is your computer?

Windows 11 x64, NT 10.0.26200.

What issue are you seeing?

A local Codex thread finishes successfully in the backend, but the visible primary window remains indefinitely in the Thinking state.

This reproduced twice, including after a full app restart. In both reproductions, the hidden desktop pet / realtime voice renderer (avatarOverlay) resumed the thread first and became the stream owner. The visible primary renderer then became a follower. New turns were actually started by the hidden overlay. After the backend wrote the final answer and task_complete, the primary window did not clear its streaming state.

The affected thread was:

019d80c8-599d-7a02-8b51-7930193b628a

Local state also showed:

• custom desktop pet selected/awake: custom:railbot
• realtime voice most-recent thread: the same affected thread
• the avatarOverlay renderer was created even while rendererWindowVisible=false

What steps can reproduce the bug?

1. Use Codex Desktop on Windows with a desktop pet / realtime voice overlay configured.
2. Open an existing local thread that is also recorded as the recent voice thread.
3. Restart Codex Desktop.
4. Open the same thread in the visible primary window.
5. Send a normal prompt.
6. Wait for the backend to complete.
7. Observe that the transcript has a final answer and task_complete, and thread APIs report idle, while the visible window continues to show Thinking.

Restarting alone does not resolve the issue because the overlay is recreated and becomes the stream owner again.

Reproduction evidence

Reproduction 1

• Turn: 01a01420-d20e-7352-a2e1-b8690b1ccb91
• Local time: 2026-08-18 17:08:10 to 17:11:05 (UTC+08:00)
• Duration: 174.681 s
• Result: completed, error=null, transcript contains final answer and task_complete

Desktop log sequence:

avatarOverlay: rendererWindowVisible=false, role=owner
maybe_resume_success: latestTurnStatus=completed, markedStreaming=true
primary renderer: role=follower
turn/start: originWebcontentsId=<hidden avatarOverlay>

Reproduction 2

• Turn: 01a0142d-b139-7931-b703-b6b4aceac42c
• Local time: 2026-08-18 17:22:14 to 17:22:41 (UTC+08:00)
• Duration: 27.348 s
• Result: completed, error=null, transcript contains final answer and task_complete

The same ownership sequence occurred again:

09:20:34Z hidden avatarOverlay webContentsId=3 -> role=owner
09:20:36Z thread/resume -> latestTurnStatus=completed, markedStreaming=true
09:20:40Z visible primary webContentsId=1 -> role=follower
09:22:14Z turn/start -> originWebcontentsId=3 (hidden avatarOverlay)
after completion, visible primary remained role=follower

There were no authentication failures, 429/5xx responses, model timeouts, stream disconnects, context-limit errors, or backend task failures.

A separate legacy_notify hook emitted Windows os error 206, but the log says after_agent hook failed; continuing, followed by task_complete. This looks secondary and does not explain why the primary renderer consistently becomes a follower.

As a control, a separate diagnostic thread owned directly by the visible primary renderer updated and completed normally.

What is the expected behavior?

• If latestTurnStatus is completed, failed, or interrupted, resume should not leave the thread marked as streaming.
• A hidden avatarOverlay should not indefinitely retain stream ownership over a thread displayed in the primary window.
• The visible primary renderer should receive/reconcile the terminal lifecycle event and immediately clear Thinking.
• On focus or thread/read, the UI should reconcile against the authoritative backend status (idle) instead of preserving stale follower state.

Additional information

No raw transcript, database, or full logs are attached because they contain private local task data and filesystem paths. Sanitized excerpts and exact timestamps can be provided if maintainers request them.

Related but not identical:

• #19690 — completed/failed turns restored with markedStreaming=true on macOS
• #24302 — inconsistent pet tray thread status

This report was prepared with AI assistance from local diagnostic evidence and submitted with the user's approval.

Start by tracing the avatarOverlay and primary renderer ownership transitions around thread/resume, turn/start, task_complete, focus, and thread/read. Compare the completed, failed, and interrupted resume paths with the visible renderer's state reconciliation. Done means a hidden overlay cannot leave the visible primary window in Thinking after the authoritative thread status is idle.