[macOS App] Orphaned inProgress turn hides later completed turns and survives restart

What version of the Codex App are you using?

• Codex Desktop: 26.818.32112
• CFBundleVersion: 6933

What platform is your computer?

• macOS 26.3.2 (build 25D2140)
• Apple Silicon (arm64)

What issue are you seeing?

A long-running Codex Desktop thread contains one orphaned historical turn whose tool work finished, but whose terminal lifecycle event was never persisted.

The affected turn remains:

status: inProgress
completedAt: null

The app subsequently accepted many new user turns in the same thread. Those later turns produced normal assistant final messages and matching completion events, and they remain present in the local rollout JSONL. However, the Desktop UI and thread reader continue to give precedence to the older orphaned turn, so the visible conversation is truncated at that Friday turn and the completed Saturday/Sunday conversation is hidden.

Restarting Codex does not repair the state. The underlying conversation data is not deleted; thread reconstruction is blocked by the stale orphaned turn.

No host reboot, deliberate app termination, or destructive command was observed at the boundary where this occurred.

Diagnostic evidence

The local append-only rollout contains this sequence:

1. task_started for the affected turn.
2. Normal assistant commentary and multiple command/tool events.
3. The final visible tool event is marked completed.
4. No matching task_complete, turn_aborted, final assistant message, failure event, or cancellation event is present for that turn.
5. The very next rollout ordinal starts another task.
6. Many subsequent turns contain valid final assistant messages and task_complete events.
7. After multiple app restarts, thread inspection still returns the old orphaned turn as inProgress with completedAt=null, ahead of the later completed history.

For the affected rollout, a lifecycle audit found:

• 39 task_started events
• 35 task_complete events
• 2 valid turn_aborted events
• 1 historical orphaned turn
• 1 currently active turn at the time of inspection

The exact local thread/turn UUIDs, repository path, task contents, and rollout file path are intentionally omitted from this public report. They remain available locally if a private diagnostic channel is provided.

Steps to reproduce the bug

A deterministic trigger is not yet known, but the observed sequence was:

1. Use a long-running Codex Desktop project thread on macOS.
2. Run a turn containing several normal tool/command operations.
3. The last tool operation completes successfully.
4. The turn fails to emit/persist any terminal lifecycle event.
5. Continue the same thread with additional user messages.
6. Observe that later turns can execute and complete normally.
7. Restart Codex and reopen the thread.
8. Observe that the timeline remains truncated at the old inProgress turn and later completed turns are not displayed.

Expected behavior

Codex should enforce and recover the turn lifecycle invariant:

1. Every accepted task_started event must eventually have exactly one terminal event: completed, failed, cancelled, interrupted, or aborted.
2. Before accepting a new turn, any prior active turn in the same thread should be terminalized or explicitly superseded.
3. On startup, the app should reconcile orphaned turns left by process interruption or event-write failure.
4. A historical orphaned turn must not hide later authoritative rollout events and completed turns.
5. The UI should expose a safe force-stop/reconcile action when no live backend execution is attached to an inProgress record.

Workaround

A new recovery thread was created from the same working-tree state with a complete context handoff. This restores work continuity but does not repair the original thread or make the hidden completed turns visible there.

Related issues

This appears closely related to #41475, which reports later durable messages being truncated behind an orphaned turn after a Windows reboot. The important difference here is that this occurred on macOS without an observed host reboot, and the orphaned turn's last tool call had already completed normally.

It is also related to #29901 and #28499, but this report includes direct rollout evidence that later turns completed normally and are specifically hidden by one older missing terminal event.

The report names no source files, tests, or entry points, so begin by locating the macOS Desktop thread reconstruction and turn-lifecycle handling described in the issue. Reproduce or inspect the orphaned inProgress case, then verify that startup and new-turn handling terminalize or supersede stale turns without hiding later completed rollout events.