Codex Desktop attachment-only tasks become undiscoverable, causing multi-million-token duplicate reruns

Summary

Codex Desktop can successfully complete a task whose initial request is stored only in a pasted-text attachment, while leaving both first_user_message and preview empty. The intact, unarchived task then becomes undiscoverable in normal project history/search even though it can still be opened by exact task ID.

This has caused measurable usage loss: after completed tasks appeared to be missing, I reran the same request several times. A read-only local audit confirmed 4,255,944 raw model tokens across three additional hidden reruns. Counting the final rerun that restored an accessible task, avoidable duplicate computation beyond the first execution was 5,922,304 raw model tokens.

These are local Codex token-telemetry totals, not a billing ledger or a claim about the private Pro-plan accounting formula.

Environment

• ChatGPT/Codex Desktop 26.721.31836 (build 5828)
• macOS 26.5.2, Apple silicon
• ChatGPT Pro
• Observed across multiple recent Codex runtime versions, including 0.145.0-alpha.27, 0.145.0-alpha.30, and 0.146.0-alpha.3

Reproduction

1. Paste a sufficiently large request so Desktop converts it to a pasted-text attachment.
2. Send it with no ordinary inline text in the request body.
3. Let the task finish normally.
4. Return to the project later or restart Desktop.
5. Look for the task in normal project history/search.

Actual

• The task is absent from normal discovery surfaces.
• Its local rollout is intact.
• Its local thread row is unarchived and has a generated title.
• Its final turn is completed with no recorded turn error.
• Opening it by exact task ID succeeds.
• first_user_message and preview are empty.

Expected

A successfully completed, unarchived task should remain discoverable regardless of whether the first request arrived as inline text or as a pasted-text attachment.

Read-only audit results

I reconciled the local thread store, rollout inventory, session index, and supported exact-ID reader without modifying or reindexing any Codex data.

Over a 30-day window:

• 174 user-started root tasks
• 15 attachment-only starts
• 8 completed, active tasks with intact rollouts but empty previews and no normal UI discovery
• 6 other attachment-only tasks that became discoverable only after a later inline user message populated the preview
• 1 intentionally archived attachment-only task
• affected active tasks spanned 3 separate local workspaces

All 8 active hidden tasks:

• exist in the local thread store and session index
• have intact rollout files
• completed without a recorded turn error
• open successfully by exact ID
• have an empty preview
• began with an attachment-only request and an empty inline body

The local thread-store schema also defines visible-thread indexes with the predicate preview <> '', which makes an empty preview a direct discovery risk.

The useful control case is an attachment-only task that later received normal inline follow-up text. That follow-up populated the preview, after which the task became discoverable.

Measured duplicate-execution damage

Five root tasks used byte-identical copies of the same private prompt attachment; no prompt text, content digest, task ID, title, or workspace name is included here.

| Execution group | Raw model tokens |
| --- | ---: |
| First execution | 486,361 |
| Three additional completed reruns that also remained hidden | 4,255,944 |
| Final rerun that became accessible after inline follow-up | 1,666,360 |
| All five executions | 6,408,665 |
| Avoidable computation beyond the first execution | 5,922,304 |

The strict directly confirmed loss is the three additional hidden reruns: 4,255,944 raw model tokens. The larger 5,922,304 figure includes the final recovery rerun, which was useful only because the earlier completed tasks were not discoverable.

I am not converting these values into dollars, credits, or a weekly-plan percentage because the backend weighting formula is not available in local telemetry.

Why this is a standalone impact report

This appears to be the same root-cause family as:

• #25924
• #26376
• #29323
• #29069
• #27159

I am not claiming a different trigger. The additional evidence in this report is:

• a 30-day denominator rather than one isolated task
• confirmation across 3 independent workspaces
• exact reconciliation showing completed tasks remain intact and openable
• the empty-preview correlation and inline-follow-up control
• directly measured multi-million-token duplicate rerun damage
• persistence on the current Desktop build

The defect is therefore not only a history-display inconvenience. It can make users believe consequential work never ran, cause repeated execution, consume plan capacity, and undermine confidence in their own task tracking.

Requested fixes

1. Populate a safe preview fallback for attachment-only first turns.
2. Do not exclude a valid, unarchived task solely because preview is empty.
3. Backfill or reindex existing intact tasks affected by this condition.
4. Add a supported recovery/inventory surface for locally intact tasks missing from project history.
5. Add a regression test covering an attachment-only first request, successful completion, no inline follow-up, and a Desktop restart.
6. Consider warning before submitting byte-identical attachment content again when an intact recent completed task already exists.

Privacy boundary

This report intentionally excludes private prompt contents, attachment contents and hashes, task IDs, local paths, user/account identifiers, project or client names, screenshots, and raw rollout/database files. I can provide maintainers with additional sanitized aggregate diagnostics if needed.