Desktop app repeatedly fails to resume a Codex thread after encrypted tool-output decode error #36662

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   tool-callsIssues related to tool callingIssues related to tool calling

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Aug 3, 2026
2. github-actions commented on Aug 3, 2026

   

   github-actionsbot

   on Aug 3, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows][Codex app] Resuming a thread with unfinished in-app Browser calls consistently crashes the app #35632

   Powered by Codex Action
3. Burlin-C commented on Aug 3, 2026

   

   Burlin-C

   on Aug 3, 2026

   Author

   More actions

   Update: the recovery fork also reproduced the same failure.

   A same-directory fork that excluded the original unfinished turn, thread 019fc581-056e-73a3-96f6-845e5027c4ab, initially resumed normally and completed a read-only recovery audit. Its next long turn then showed the same Encrypted function output content could not be decrypted or decoded error and is now marked systemError.

   This weakens the earlier observation that excluding the unfinished turn was sufficient. The recurrence is consistent with a broader desktop-app/session or streamed tool-output handling problem, not solely corruption of one persisted unfinished event. No logs, project files, or conversation content are attached.
4. JiaqiLiRonnie commented on Sep 4, 2026

   

   JiaqiLiRonnie

   on Sep 4, 2026

   More actions

   This issue also reproduces in an interactive Desktop case on macOS, with the same recovery behavior:

   • Restarting the app did not by itself make the original thread resumable.
   • A normal fork created from the latest history also failed because its history base still included the persisted failed/encrypted records.
   • After a backup, removing only unreadable encrypted_content payloads and repairing the paginated history_base byte offsets, a fork completed a no-op turn successfully. The original parent could load again but remained much slower because its history was substantially larger.

   This suggests that recovery should not simply copy the current end of a broken thread. A useful UI recovery path would fork from the last known-good completed turn, rebuild a replayable text checkpoint, or explicitly omit invalid streamed tool-output items. The UI should also distinguish a recoverable systemError from an indefinitely inProgress turn instead of looping reconnection attempts.