Codex Desktop session stuck as follower after backend thread is idle

What version of the Codex App are you using (From “About Codex” dialog)?

26.519.41501

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Environment:

• Codex Desktop macOS
• Version: 26.519.41501
• CLI could continue the same thread successfully
• Desktop rendered the thread but kept spinner/status active and blocked Send/Stop

Symptoms:

• Desktop showed the session as still running.
• Send was blocked.
• Stop did not recover the session.
• Restarting Desktop did not fix it.
• CLI could load/continue the session.

Diagnostics:

• Backend thread/read returned the thread as idle/complete.
• Backend thread/resume returned idle/complete state.
• Desktop renderer thread-role-for-host returned follower.
• assert-thread-follower-owner-for-host failed with:

"Please continue this conversation on the window where it was started."

• Clearing Desktop stream roles and then running the normal resume path with workspaceRoots changed the role to owner and recovered the thread.

Expected:
If backend state is idle/complete and no owner window exists, Desktop should not keep the thread blocked as a follower. It should either clear the stale follower role or resume ownership.

Actual:
Desktop kept a stale follower/owner routing state even though the backend thread was idle.

Related: #20754, #12852, #21360. This may be the same family of bug, but this report adds a more specific diagnostic: Desktop stayed in follower mode while backend thread state was idle/complete.

What steps can reproduce the bug?

I do not have a deterministic minimal reproduction yet.

Observed reproduction pattern:

1. Use Codex Desktop on macOS with a local workspace.
2. Work in a thread for multiple turns.
3. At some point, the Desktop UI keeps showing the thread as active/spinning even though the underlying task has completed.
4. Reopen/restart Codex Desktop.
5. The same thread still renders content, but the status remains active/spinning and Send/Stop are blocked.
6. Load or continue the same thread from Codex CLI.
7. CLI can continue the thread successfully, but Desktop still treats the thread as blocked.
8. Inspecting Desktop renderer state showed the thread role as follower, while backend thread/read and thread/resume returned the thread as idle/complete.
9. Clearing Desktop stream roles and then triggering the normal resume path with workspaceRoots changed the role to owner and recovered the thread.

The important diagnostic shape is: Desktop follower/owner routing state was stale while backend thread state was idle.

What is the expected behavior?

Codex Desktop should not keep a local thread blocked as a follower when the backend thread state is idle/complete and no owner window is available.

Expected behavior:

• If the backend reports the thread as idle/complete, Desktop should clear any stale active/spinning UI state.
• If a follower/owner route is stale, Desktop should recover ownership or fall back to a normal resume path.
• Send and Stop should not remain blocked indefinitely.
• Restarting Desktop should not restore the same stale follower state.
• Desktop and CLI should agree on whether the thread is usable.

Additional information

Additional diagnostics from the affected run:

• Codex Desktop version: 26.519.41501
• Platform: macOS arm64
• CLI could load/continue the same thread while Desktop could not.
• Desktop thread-role-for-host returned follower.
• Desktop assert-thread-follower-owner-for-host failed with:

"Please continue this conversation on the window where it was started."

• Backend thread/read returned the thread as idle/complete.
• Backend thread/resume returned the thread as idle/complete.
• The Desktop app-state snapshot showed stale streaming/follower counters before repair, including streaming follower threads without active runtime.
• Running discard-conversation-from-cache for the affected conversation reduced the stale counters but did not fully recover the thread.
• Running mark-all-conversations-need-resume-after-reconnect-for-host cleared the streaming/follower counters.
• Triggering the normal resume path with the required workspaceRoots then changed the thread role from follower to owner, and the thread became usable again.