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

Open 💬 6 comments Opened Aug 18, 2026 by zgl-gits

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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?

Use Codex Desktop on Windows with a desktop pet / realtime voice overlay configured.
Open an existing local thread that is also recorded as the recent voice thread.
Restart Codex Desktop.
Open the same thread in the visible primary window.
Send a normal prompt.
Wait for the backend to complete.
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.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 10 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#38629

Powered by Codex Action

zgl-gits · 10 days ago

Workaround / diagnostic update (2026-08-18)

The affected UI recovered immediately after the user toggled the desktop pet setting off and back on.

Observed result:

The stale Thinking indicator cleared.
The affected thread became usable and displayed its completed state normally.
No model, reasoning-effort, context-window, session transcript, database, or Codex configuration changes were made.

This strengthens the hypothesis that the failure is in avatarOverlay stream ownership / renderer-state synchronization. Toggling the pet likely destroys, recreates, or rebinds the overlay and allows the visible primary renderer to reconcile with the authoritative completed/idle backend state.

This is a confirmed one-time workaround on the affected Windows installation. It has not yet been verified whether the fix survives another full app restart or prevents future recurrence.

Tarrriq · 8 days ago

### Workaround / diagnostic update (2026-08-18) The affected UI recovered immediately after the user toggled the desktop pet setting off and back on. Observed result: The stale Thinking indicator cleared. The affected thread became usable and displayed its completed state normally. * No model, reasoning-effort, context-window, session transcript, database, or Codex configuration changes were made. This strengthens the hypothesis that the failure is in avatarOverlay stream ownership / renderer-state synchronization. Toggling the pet likely destroys, recreates, or rebinds the overlay and allows the visible primary renderer to reconcile with the authoritative completed/idle backend state. This is a confirmed one-time workaround on the affected Windows installation. It has not yet been verified whether the fix survives another full app restart or prevents future recurrence.

I had the pet off already, turning the pen on and off again solved the problem.
Thank you

cyphersys · 7 days ago

### Workaround / diagnostic update (2026-08-18) The affected UI recovered immediately after the user toggled the desktop pet setting off and back on. Observed result: The stale Thinking indicator cleared. The affected thread became usable and displayed its completed state normally. * No model, reasoning-effort, context-window, session transcript, database, or Codex configuration changes were made. This strengthens the hypothesis that the failure is in avatarOverlay stream ownership / renderer-state synchronization. Toggling the pet likely destroys, recreates, or rebinds the overlay and allows the visible primary renderer to reconcile with the authoritative completed/idle backend state. This is a confirmed one-time workaround on the affected Windows installation. It has not yet been verified whether the fix survives another full app restart or prevents future recurrence.

I confirm your workaround. Thank you!

itokenchiku · 7 days ago

I can corroborate a closely related Windows Desktop failure involving realtime voice.

Observed behavior:

A delegated child task had already completed and returned its result, but the visible parent thread continued to show Thinking / a running-command indicator indefinitely.
While the stale running state was present, starting a realtime voice session also became unavailable or failed to start.
Closing and reopening the Codex app did not reliably recover the state.
Fully terminating the Codex/ChatGPT process tree in Task Manager, or rebooting Windows, restored normal behavior.
This was not caused by the child task's filesystem permission failure; that was a separate scoped sandbox denial, while the stale UI/voice state remained at the app/session layer.

This matches the hypothesis that a hidden realtime/overlay or background process retains stale stream ownership after the backend work has completed. From the UI alone, it was impossible to distinguish genuine execution from a stale Thinking state.

Suggested UX/recovery behavior:

Reconcile the visible thread with authoritative backend completion state.
Clear stale streaming ownership when the backend turn is terminal.
Show whether a command is actually running versus only a stale UI state.
Provide an in-app recovery action that resets the realtime/overlay session without requiring process-tree termination or a PC reboot.

No customer data, local paths, transcript content, or credentials are included in this report.

Fireotics · 6 days ago

am geting {"detail":"Bad Request"} Error for each Task and wont work.