[macOS Desktop] Archive → immediate unarchive reloads stale transcript and loses newer conversation history

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

ChatGPT/Codex desktop 26.810.52044 (build 6662); bundled codex-cli 0.148.0-alpha.15.

What subscription do you have?

Unknown. The app is signed into a ChatGPT account with Codex access, but the plan is not exposed in the available local diagnostics.

What platform is your computer?

Darwin 25.5.0 arm64 arm

macOS 26.5.2 (build 25F84).

What issue are you seeing?

Archiving the currently viewed local Codex task and immediately unarchiving it caused the transcript to revert to an old persisted snapshot. Many later user and assistant turns disappeared.

This was not only a sidebar visibility problem:

• The unarchived task opened successfully, but only the earliest five turns remained.
• A subsequent thread/read returned the shortened history with hasMore: false and nextCursor: null.
• The surviving local rollout JSONL also lacks the missing conversation text.
• The archived task list is empty after restoration.
• A 167-line CSV generated during the missing work still exists, independently confirming that the work occurred even though the associated transcript is gone.

The Desktop feedback UI does not provide a file-attachment control, so I cannot attach the sanitized diagnostic report or local logs there. I have retained a local backup, but I am not uploading the raw archive publicly because it contains conversation text, account/task identifiers, and local paths.

What steps can reproduce the bug?

Observed sequence (timestamps sanitized to relative time; all operations were successful at the API level):

1. Open an existing local/projectless Codex task that has a long visible transcript and generated artifacts.
2. From the Recent Tasks menu, archive the currently viewed task.
3. Approximately five seconds later, unarchive the same task.
4. Reopen/inspect the restored task.
5. Observe that the transcript has reverted to an earlier state and newer user/assistant turns are gone.

Sanitized client-log sequence:

T+0.000s  Archive requested, source=recent_tasks_menu
T+0.026s  current task active=false
T+0.038s  window route changes to / and binds a new client-new-thread
T+0.186s  method=thread/archive succeeds
T+0.188s  browser-use route and conversation for original task are disposed
T+0.552s  method=thread/start creates a new temporary thread

T+5.075s  Unarchive requested for original task
T+5.094s  method=thread/unarchive succeeds
T+5.095s  Unarchive succeeded
T+5.107s  method=thread/read for original task
T+5.109s  second method=thread/read
T+5.123s  third method=thread/read from the avatar overlay

A prior resume log already reported turnCount=5 for this task even though the window later displayed additional work. This suggests that the visible later transcript may have remained only in renderer memory, an ephemeral thread, or another state that was never durably bound to the task.

Across the same four-day log window, 37 distinct IDs emitted:

Received turn/started for unknown conversation

No full local path, account ID, raw prompt, hostname, or unredacted task ID is included here.

What is the expected behavior?

• Archive/unarchive must preserve every persisted user message, assistant response, commentary item, tool result, and generated-file reference.
• Archiving the currently viewed task must not dispose the only copy of transcript state.
• Before disposing the active route, Desktop should ensure all visible turns are durably committed and bound to the correct task.
• If the renderer contains turns that are not present in persisted storage, archive should block with a recoverable warning or synchronize them first.
• Unarchive should restore the same transcript that was visible before archiving, not an older snapshot.
• The feedback UI should allow users to attach sanitized logs or diagnostic files for data-loss reports.

Additional information

The evidence supports this likely mechanism:

1. Some newer visible turns were not durably persisted or correctly bound.
2. Archive set the task inactive, switched the window to a new temporary thread, and disposed the original route/conversation.
3. Unarchive successfully reloaded the original task via thread/read.
4. Only the old backend snapshot was available, so the UI appeared to "jump back to the beginning."
5. The newer in-memory/unmaterialized transcript could no longer be recovered.

Archive/unarchive appears to be the trigger that exposes the loss; the underlying persistence or conversation-binding failure likely occurred earlier.

Related but not exact duplicates:

• #26012: restored UI loses command/tool details, but the raw rollout JSONL still contains them. Here, complete user/assistant turns are missing and the rollout lacks them.
• #33860: unarchive returns an error while storage mutation succeeds; here, unarchive returned success but loaded a stale/truncated transcript.
• #39011: entire assistant messages disappear after turn/steer; this report has a deterministic archive/unarchive trigger and includes missing user/assistant history.

Impact: severe. Long-running task context and decisions can be silently lost, while generated files remain and prove the work occurred. Users cannot trust Archive as a reversible operation.