macOS desktop task history freezes at Thursday: duplicate ordinal 12165 at stalled projection offset while Sunday transcript remains intact #43451

Summary

A long-running local desktop task repeatedly reopens at an old Thursday checkpoint, hiding Friday–Sunday messages even though the durable rollout contains those actual user/assistant messages. Read-only inspection found a duplicated serialized ordinal exactly at the stalled history projection offset.

Possibly the same defect as #43124 and #41566; this adds a macOS reproduction with the duplicate record and projection cursor directly compared. No claim that the original transcript was deleted.

Environment

• Desktop app: 26.901.20858 (CFBundleVersion 7658), installed as ChatGPT.app with the Codex task interface.
• Bundled Codex: codex-cli 0.153.0-alpha.5.
• Affected thread metadata records writer CLI version 0.150.0-alpha.8; this is not assumed to be the current writer.
• Separately installed standalone CLI: 0.146.0 (diagnostic version check only).
• macOS 26.6.2 (25G83), arm64.
• Incident observed September 7, 2026, America/Chicago.
• Thread history mode: paginated.

User-visible behavior

The newest historical turn returned by the desktop task-reading interface is a turn started September 3 at 17:41 Central. It remains marked in progress in the derived history. The user worked through Sunday evening, but reopening the same task presents the older checkpoint.

The canonical transcript contains actual later messages, including a Sunday September 6 21:58 Central assistant completion, a subsequent user approval, and a 22:53 Central assistant final response. The underlying project commit and prepared artifacts also remain intact. This is a history reconstruction failure, not evidence of reverted project files.

Read-only evidence

For the affected thread, thread_history_projection_state repeatedly returned:

next_rollout_byte_offset = 134855731
next_rollout_ordinal = 12166

Derived thread_items:

row count = 3552
maximum rollout_ordinal = 12163
maximum created_at_ms = 1788475443401

At byte offset 134855731 in the canonical rollout, the next record is:

physical line: 12167 (1-based)
previous record's serialized ordinal: 12165
current record's serialized ordinal: 12165
timestamp: 2026-09-03T23:00:59.447Z
type: event_msg
payload.type: thread_settings_applied

The following record is task_started with ordinal 12166. Thus the cursor expects 12166 but encounters a second 12165 at exactly its next byte offset.

A complete streamed scan at the later diagnostic snapshot read 24,522 JSONL records / 973,690,804 bytes and found this single serialized-ordinal discontinuity. An earlier complete JSON parse found zero malformed JSON lines. The transcript continues through Sunday and the current Monday conversation; it was not truncated at the projection boundary.

The normal newest-first task-history lookup returns the old September 3 turn even though thread metadata's updated time is current. This independently reproduces the user's UI observation.

Observed sequence

1. Continue a local desktop task across several days with tool output and images.
2. Leave and reopen the task.
3. See historical messages stop at an older Thursday turn.
4. Compare the same task's raw rollout with the derived history tables, read-only.
5. Find a duplicate ordinal at the exact stalled projection offset while later messages remain present in the rollout.

The initiating event that wrote the duplicate is unknown. The evidence localizes the inconsistency; it does not establish whether a particular resume, compaction, update, or interruption caused it. No matching explicit projector error was found in the narrowly inspected September 6–7 desktop text logs.

Expected behavior

• Reopening the task should expose all durably saved messages.
• Detect and safely recover a duplicate ordinal, or show a clear actionable history-reconstruction error instead of silently presenting stale history.
• Provide a supported non-destructive per-thread verification/reindex/recovery path.
• Preserve original transcript data and make any recovery auditable.

Privacy / actions taken

This report contains sanitized structural metadata only. No thread UUID, personal paths, project names, conversation bodies, screenshots, credentials, signed URLs, raw logs, or database/transcript files are attached. All diagnostic database opens were read-only. No history database rows or original rollout files were edited/deleted, and no reset/reinstall/reindex was attempted.