Desktop app: archiving and unarchiving does not recover zombie threads stuck on Thinking

[twentyOne2x]

Summary

In the Codex macOS desktop app, a thread that is already in a zombie/stuck state remains broken after being archived and then unarchived.

Problem

Archiving and unarchiving does not reset or recover the thread state. After restore, the thread can still show the broken Thinking / Interrupt-only UI and remain unusable.

Observed behavior

• A thread enters a zombie state
• The thread is archived and later unarchived
• After restore, it is still stuck / unusable
• The composer state is still broken instead of returning to a normal send state

Expected behavior

Either:

• unarchiving should restore a usable thread state, or
• the app should detect the broken thread state and surface a recovery path instead of preserving the zombie state forever

Platform

macOS desktop app

Related

Likely related to zombie/stuck-thread reports such as #12852 and #11902, but this report is specifically about archive/unarchive not clearing the broken thread state.

[github-actions]

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

• Codex Desktop threads stuck in “Thinking” and cannot be stopped unless background process is force-killed #12852
• Codex stale-thinking spinner persists after stream state desync (thread stale detection + targeted recovery results) #12955
• Codex stale-thinking thread spinner may persist after stream-state mismatch #12954

Powered by Codex Action

[etraut-openai]

I wouldn't expect archiving to fix a broken thread.

If you have details about a "zombie" thread, please open a bug report or respond to an existing one. Use the /feedback slash command to upload the session and include the thread ID in your report.