Repository navigation
[Windows 26.901.6511.0] Reopened task shows older history although recent final answers remain persisted #43935
Description
Environment
Codex desktop on Windows, package version 26.901.6511.0 (verified in local application log paths). Long-running local task. Exact subscription tier and bundled backend version were not measured in this investigation.
User-visible problem
The user repeatedly reports that the application becomes stuck and, after restarting, the task appears to return to older conversation content. This creates uncertainty about completed work and prompts manual recovery from copied responses.
Evidence from the affected machine
A bounded, read-only inspection of public event metadata on 2026-09-08 found:
- Three recent assistant final answers remain in the local session JSONL: 18:28:50.025 UTC, 18:43:21.171 UTC, and 20:02:01.121 UTC, with lengths 4595, 409, and 3511 characters.
- Each has a subsequent
task_complete; the latest is 20:02:02.213 UTC. - Application
stop_process: 21:53:09.757 UTC;Launching app: 21:53:13.085 UTC. - Session JSONL size at inspection: 347,061,221 bytes. The inspected trailing 16 MB parsed without errors; total-file integrity was not checked.
Earlier on the same day, logs recorded these sanitized fields:
2026-09-08T04:00:31.491Z Request failed
code=-32001 message="App server request expired while queued"
method=thread/turns/list source=tail_history durationMs=60005
pendingCountAfter=25
2026-09-08T04:07:49.277Z Request failed
code=-32001 message="App server request expired while queued"
method=thread/turns/list source=tail_history durationMs=60011
pendingCountAfter=29
2026-09-08T04:08:51.696Z Request failed
message="App server request expired while queued"
method=turn/start durationMs=30012
2026-09-08T04:11:05.391Z Request failed
message="App server request expired while queued"
method=turn/start durationMs=30005
Evidence limits
After the latest restart, thread/resume succeeded at 21:53:50.411 UTC, and thread/turns/list succeeded at 21:53:50.493, 21:53:54.026, and 21:53:54.098 UTC. Therefore, the earlier queue failures do not establish the cause of the latest restart or prove the newest history payload was wrong.
Recent persisted answers were not lost in the inspected file. A history loading, pagination, projection, or rendering issue is a hypothesis, not a demonstrated root cause. No deterministic minimal reproduction or renderer capture is available.
Separately, an agent-maintained local recovery note had an outdated heading with newer updates at its end. Its heading was corrected. That can explain stale task resumption by the agent, but is not evidence that it caused the application hang or visible history behavior.
Observed sequence
- Continue an existing long-running task.
- The application becomes stuck, according to the user.
- Restart the application.
- Reopen the task; the user sees older content and has to paste a saved recent response.
- Local inspection still finds the recent final answers and completion events.
This is an intermittent incident sequence, not a deterministic reproduction.
Expected behavior
Reopening a task should restore the latest persisted turns and distinguish history-loading failure from missing data. Older-history loading should not prevent interactive recovery. Please investigate the cursor/pagination/projection and renderer path alongside queue behavior.
Potentially related: #43525, #36914, #21211. Please consolidate if this is the same issue; this report adds evidence of persisted final answers versus user-visible history regression.
No full logs, session contents, local usernames/paths, task IDs, credentials, project code, or customer data are attached.
Activity
github-actions commentedon Sep 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
impulsodigitalpty commentedon Sep 9, 2026
Additional reproduction observed on 2026-09-09 around 11:51–11:55 UTC, on the same Windows machine.
This time the stale-history mismatch is visible through the native task tools, not only reported by the user:
This narrows the observation: live task status/updatedAt and the native history projection disagree. Recent events still exist in the inspected local session, so this does not establish deletion, nor identify the internal cause of the hang. A separate project-specific tool rejection explains the most recent workflow stop; it should not be conflated with this history-loading bug.
Reproduction tools used: list_threads, read_thread, wait_threads(timeoutMs=0), one send_message_to_thread, and a bounded read-only local tail inspection. No session database edits or app-server workarounds were used. Please inspect newest-first pagination/projection and the 200-item window in long tasks.
No task IDs, local user paths, project text/code, credentials, or customer data are included.
Jerryugcat commentedon Sep 9, 2026
Additional Windows reproduction observed on 2026-09-09.
User-visible symptom: after closing Codex Desktop and reopening the same long-running task, recent conversation/work records are no longer visible in the task UI. The user has to manually paste prior context back in to continue safely.
Observed context:
Expected behavior: closing/reopening Codex Desktop should restore the latest persisted user-visible conversation for the task. Internal context compaction should not make recent user/assistant/tool history disappear from the UI. If history projection/loading fails, the app should surface an explicit recoverable error and rebuild/reindex from the durable session record rather than silently showing stale history.
I’m intentionally not attaching private project paths, task contents, screenshots, or customer data. Exact Codex Desktop version was not captured in this reproduction.