Windows Desktop: reopening a long thread restores an old message instead of the latest content

Open 💬 4 comments Opened Jul 26, 2026 by ytr028295-lab

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Codex Desktop for Windows, reopening a long local thread from the left sidebar consistently restores the viewport at the same old cross-thread status message instead of the latest content. Sending new messages, switching away and back, and manually jumping to the bottom do not update the persisted reopening position.

This is not an old deep-link/notification route: the issue reproduces when opening the thread directly from the sidebar.

Environment

Codex Desktop: 26.721.4979.0
Platform: Windows x64
Thread shape: long local thread, approximately 175 turns, with many collapsed processed/activity blocks and background updates

Reproduction

Open a long existing thread from the left sidebar.
Scroll or jump to the latest content.
Send/receive newer turns.
Switch to another thread.
Reopen the affected thread from the sidebar.
Observe that the viewport returns to the same old message rather than the latest content.

Expected behavior

Opening a thread from the sidebar should land at the newest content, or at minimum preserve the most recently viewed bottom position. A visible, reliable “jump to latest” control should remain usable after history pagination completes.

Actual behavior

The app always lands on the same historical message. This makes the current status look stale and, in long-running supervision threads, can make an obsolete pause message appear current.

Local diagnostic evidence

A desktop log captured during sidebar reopen shows:

thread/read succeeds.
thread/resume succeeds.
The latest turn is reported as latestTurnStatus=completed while the renderer simultaneously records markedStreaming=true.
The thread reports about turnCount=175.
Immediately afterward, the renderer performs many sequential thread/turns/list requests while loading history.

This suggests a renderer resume-state mismatch combined with virtualized/paginated history anchor restoration. The underlying thread is current; the failure is in viewport positioning/render recovery.

Workarounds tried

Open from the sidebar rather than an old notification/deep link.
Ctrl+End after loading.
Switch to another thread and return.
Send newer messages from the bottom.

These only help temporarily; reopening still returns to the same old message.

Related issues

#17193 — long threads jump away while navigating toward latest output
#17169 — chat scroll position bounces in long conversations
#19690 — completed/failed turns restored with markedStreaming=true
#17536 — reliable navigation to latest assistant response / message blocks

Privacy

Conversation IDs, local paths, project names, account data, and message contents are intentionally omitted. Full sanitized log excerpts can be provided if maintainers request them.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#35178

Powered by Codex Action

ee- · 16 days ago

I can confirm a similar issue in the Codex desktop app on macOS as of August 11, 2026.

This happens intermittently when switching back to a very long conversation. Instead of opening at the latest message / bottom of the thread, the viewport lands much higher in the conversation. Reaching the newest content then requires a very long period of manual downward scrolling.

Expected behavior: switching to an existing conversation should open at the latest content, or provide an immediately visible and reliable “Jump to latest” control. This macOS reproduction suggests that the viewport restoration problem may not be Windows-specific.

matthewkiefer · 2 days ago

I reproduced this on a newer Windows build, with a specific subagent-panel trigger.

Environment:

Codex Desktop for Windows 26.818.8289.0
bundled codex-cli 0.149.0-alpha.4.3
Microsoft Windows NT 10.0.26200.0 x64

Observed sequence:

Open a long-running parent task with native subagents.
Inspect several subagent messages/conversations in the right panel.
Close those right-panel subagent views.
The main parent transcript becomes stuck on an old completed result from several days earlier.
The parent task continues working in the background, but its current commentary is not visible in the main transcript.

Diagnostic evidence:

App-level thread listing/read reports the parent as active.
The latest parent turn is inProgress and has recent commentary.
The visible main transcript instead remains on an older completed message.
Explicit app navigation back to the parent returns success but does not move the viewport to the live turn.
The backing history is intact; this is a renderer/view-anchor problem, not task-data loss.

This reproduction did not involve intentionally selecting an old task, forking, rolling back, or steering through Remote Control. The likely trigger was opening and then closing subagent content in the right panel, after which the parent view restored a stale historical anchor.

Immediate recovery attempted: focus the Codex window and issue Ctrl+End (“jump to latest”). The task itself was not interrupted or modified.

This may overlap with #39945, but in this occurrence the visible symptom is the same-thread parent viewport pinned to an old completed message after right-panel subagent navigation.

matthewkiefer · 2 days ago

Follow-up on the 26.818.8289.0 reproduction: explicit parent navigation plus repeated Ctrl+End did not recover the view; it remained pinned to the same historical completed message while app-level thread status still showed an active current turn. I then reloaded the Desktop renderer (Ctrl+R), explicitly reopened the parent task, and issued a fresh jump-to-latest. This reinforces that the failure survives ordinary route navigation and is tied to renderer/virtualized-history anchor restoration after closing right-panel subagent content.