Windows Desktop: web-origin ChatGPT conversations reopen far from latest and lack reliable jump-to-latest

Open 💬 6 comments Opened Jul 24, 2026 by cryptomasters

Summary

A long ChatGPT conversation that was created on chatgpt.com and later continued in Codex Desktop Chat mode can reopen near the beginning or in the middle instead of at the newest message.

When this happens, reaching the latest response can be extremely slow or practically impossible, and the affected web-origin Desktop route does not provide the same reliable one-click Scroll to bottom / Jump to latest recovery control that Codex-origin local tasks already have.

No fix has been deployed to the installed application or to chatgpt.com. This issue is a bug report for the Desktop team.

Environment

Codex Desktop: 26.721.3996.0
Distribution: Microsoft Store / AppX
Platform: Windows x64
Conversation origin: created on chatgpt.com
Continuation surface: Codex Desktop, Chat mode
Conversation type: long-running conversation with substantial history
Subscription/account details: intentionally omitted

Primary affected path

This is specifically the web-origin ChatGPT conversation path:

The conversation begins on chatgpt.com.
The same conversation is later opened or continued in Codex Desktop Chat mode.
Reopening that conversation in Desktop can restore an old viewport position instead of showing the latest message.

This is not the separate Codex-origin local-task route.

Steps to reproduce

Create or use a long conversation on chatgpt.com.
Continue that same conversation in Codex Desktop Chat mode.
Leave the conversation.
Reopen it several times from the Desktop sidebar.
In the intermittent failing case, observe that the viewport opens near the top or somewhere in the middle rather than at the newest message.
Attempt to reach the latest message.
Observe that manual scrolling can take an excessive amount of time and that a reliable one-click jump-to-latest control may be missing on this route.

Actual behavior

A cold open or reopen can restore a stale mid-thread position.
The viewport may land near the beginning or middle of a very long conversation.
The newest response can become practically inaccessible.
The web-origin Desktop route lacks a reliable recovery control equivalent to the translated Scroll to bottom control already present for Codex-origin local tasks.
Reopening the conversation does not consistently recover the latest-message position.

Expected behavior

A cold open or ordinary reopen should default to the latest message.
An older reading position should be restored only when the product has an explicit, intentional resume-reading-position state.
Initial positioning should remain correct after asynchronous history hydration and content-height settling.
Any real user scroll during settling should cancel further automatic re-pinning.
Whenever the user is not near the bottom, a visible, accessible one-click Jump to latest / Scroll to bottom control should be available.
The open path should load the newest history first and must not default to a stale implicit mid-thread offset.

Impact

The user can miss the newest assistant response and may be unable to continue work in a long conversation. Repeated manual scrolling is time-consuming and can make the conversation effectively unusable.

Frequency

Intermittent, but recurring. Reopening the same long web-origin conversation multiple times makes the problem observable. Exact history length, media density, and probability have not been measured.

Diagnostic findings for the Desktop team

Inspection of the packaged Windows application indicates that the relevant screens are separate:

/work/conversation/:conversationId is handled as a chatgpt-thread and loads the ChatGPT-conversation page used for web-origin conversations.
Codex-origin local tasks use a different conversation component.
The local-task component already renders the existing translated floating Scroll to bottom control.
The web-origin ChatGPT page reads an implicit per-conversation distance-from-bottom and supplies it as the shared thread layout's initial offset while the conversation is hydrating.
No separate signal was identified in this path showing that the user explicitly chose to preserve that older reading position.
The web-origin page does not expose the same recovery control as the local-task page.

These findings suggest a stale scroll-restoration / hydration-order problem in the Desktop ChatGPT-conversation client, not a CLI/TUI issue.

Likely failure modes to investigate

A stale implicit distance-from-bottom is reused during cold open or reopen.
Initial scroll positioning runs before virtualized history and content heights settle.
Newest history may not be ready when the first viewport anchor is chosen.
Layout compensation may preserve the wrong anchor as additional content hydrates.
The web-origin route omits the existing jump-to-latest recovery control.

Requested Desktop behavior

Default cold/reopen to latest unless there is explicit preserved-reading-position intent.
Pin after first layout and once again after hydration/height settling.
Stop automatic re-pinning immediately after a real user scroll.
Reuse the existing translated local-task jump-to-latest control on the web-origin ChatGPT page.
Verify that newest history loads first.
Add regression coverage for long web-origin conversations, repeated reopen, delayed hydration, and media-heavy turns.

Additional user observation about chatgpt.com

The user also reports that the same long conversation on chatgpt.com currently has no visible Scroll to bottom control when needed.

This web observation has not been independently tested or investigated as part of this report, and it may be a separate ChatGPT web issue with a different implementation or root cause. It is included only as user-provided context; this report does not claim that the Desktop and web symptoms share one cause.

Related issues reviewed — not exact duplicates

#33768: missing scroll-to-bottom button in the macOS unified app.
#17193: long macOS threads jumping back to the top while scrolling downward.
#28755: Codex-origin sessions entering a jump/blank-view loop after using the jump-to-bottom control.
#21488: Windows Progress panel interfering with the scrollbar.

This issue remains distinct because it isolates the initial/reopen position and missing recovery UI on the Windows web-origin chatgpt-thread path.

Privacy and attachments

Conversation contents, account information, local paths, private URLs, and screenshots containing private chat data are intentionally omitted. Reproduction details can be refined without disclosing conversation content.

View original on GitHub ↗

6 Comments

rohanpatel2002 · 1 month ago

Analysis (from OSS repo inspection)

This looks like a Codex Desktop Chat-mode client bug (scroll / virtualization on conversation open), not something fixable in the public openai/codex CLI/TUI tree.

What I checked

This OSS repo has Desktop launch / codex://threads/{id} handoff and app-server history APIs (thread/resume, thread/turns/list, paginated cursors), but no Desktop Chat message-list / scrollToBottom / virtualized viewport implementation.
Labels on this issue (app, windows-os, session) match that boundary.

Hypothesis

Intermittent wrong initial viewport on open is consistent with:

Restoring a stale scroll offset (or anchoring to list head) instead of forcing “latest” on open
Applying scroll before async history / content heights settle (virtualized list + tall messages)
First paint using an incomplete / wrong history page before the newest page is ready
No reliable “jump tst” recovery path (related: #33768)

The “cannot reach bottom” symptom after a bad open matches virtualization / height-settling fighting scroll position (#17193 family), not a simple missing convenience button.

Suggested fix location / direction (for the Desktop app team)

On Chat-mode conversation open: after first layout (and once after hydrate/height settle), pin viewport to the latest message unless the user explicitly preserved another position
Keep / restore a one-click jump-to-latest control when not near bottom (#33768)
Verify open path loads newest history first and does not restore mid-thread scroll by default

Happy to refine repro details (conversation length, media-heavy turns, reopen frequency) if useful.

cryptomasters · 1 month ago

Clarification before implementing a local prototype

In the installed Windows AppX build 26.721.3996.0, the Chat-mode conversation page reads a persisted per-conversation distance-from-bottom and passes it to the shared thread layout as the initial offset while the conversation is still hydrating. Scroll events keep updating that value. I do not see a separate signal in this path for “the user explicitly preserved this reading position.”

Which behavior did you intend?

Default every conversation route open to latest (initial offset 0, then re-pin once after hydrate/height settle), ignoring the persisted mid-thread offset; or
Restore the offset only for an explicitly tracked same-session “resume reading position” action, while cold/reopen defaults to latest?

Also, local Codex conversations already render a translated floating Scroll to bottom control using the shared scroll controller, but Chat mode appears not to render that control. Is reusing the same control in Chat mode the intended recovery path?

I want to avoid hard-coding the wrong reading-position semantics.

cryptomasters · 1 month ago

Route isolation and validated prototype results

The affected conversation was created on chatgpt.com and later continued in Codex Desktop. That distinction matches the packaged app architecture:

web-origin conversations use the separate chatgpt-thread / ChatGPT-conversation page;
Codex-origin local tasks use a different conversation component and already render the translated one-click Scroll to bottom control.

In the Windows AppX build 26.721.3996.0, the web-origin page supplies an implicit per-conversation distance-from-bottom as the shared layout's initial offset. I still do not see an explicit signal that this offset represents an intentional preserved reading position.

I built a strictly isolated prototype without modifying the signed Store package. The prototype changes only the web-origin ChatGPT page:

default route open starts at latest (initialOffset: 0);
it pins after first layout and follows bounded content-size/mutation settling during hydration;
the first real user scroll cancels all further settling re-pins;
it reuses the existing translated local-task jump-to-latest control when away from bottom.

UI validation against a long web-origin conversation:

after opening: still at latest at both 1.5 s and 5.7 s after navigation;
manual wheel-up during the initial settling window: older position remained preserved after another 5.2 s;
jump-to-latest control appeared while away from bottom and returned to latest with one click;
the separate Codex-origin route remained unchanged and its existing control still worked;
no page/runtime errors were produced by these interactions.

The rebuilt archive also passed full structural/integrity validation: 5,918 entries compared, 5,881 packed entries checked, with the ChatGPT page as the only production-like changed module.

A similar symptom is often seen on chatgpt.com itself, but I am treating that as a separate validation lane until a shared implementation/root cause is confirmed.

I reviewed nearby reports again. #28755 is closely related but is not exact: it concerns Codex-origin sessions and an infinite jump loop after using the control, while this report isolates wrong initial positioning and missing recovery UI on the web-origin ChatGPT page. I am therefore leaving this issue open rather than marking it duplicate.

rohanpatel2002 · 1 month ago

Thanks — the route isolation is the key detail.

Agree this is specifically the web-origin chatgpt-thread / ChatGPT-conversation path (chatgpt.com → continued in Desktop), not the Codex-origin local-task route that already has Scroll to bottom.

Your prototype shape also matches what I’d expect for a safe default while the team answers the open questions:

cold/reopen → latest (initialOffset: 0) + bounded re-pin through hydrate/height settle
first real user scroll cancels further auto re-pins
reuse the existing translated jump-to-latest control when away from bottom

I can’t speak for intended reading-position product semantics (restore implicit distance-from-bottom vs explicit same-session resume only). Leaving that for a maintainer.

Happy to help with extra repro notes if useful: long web-origin threads, reopen frequency, and whether media-heavy turns make the bad open more likely.

cryptomasters · 1 month ago

Full report consolidated

I have updated the top-level issue with the complete environment, exact web-origin Desktop scope, reproduction steps, actual/expected behavior, impact, route diagnostics, likely failure modes, requested regression coverage, and duplicate review.

Important clarification: no fix has been deployed to the installed Codex application or to chatgpt.com. The user additionally observes that the same long conversation on chatgpt.com has no visible scroll-to-bottom control when needed; that web observation is included as user-provided context only and was not independently tested or investigated here. It may be a separate ChatGPT web issue.

Please triage the Windows Desktop chatgpt-thread reopen/scroll-restoration defect as the primary issue.

rohanpatel2002 · 1 month ago

Thanks for consolidating the report and clarifying that nothing is shipped yet. Leaving this for maintainer triage on the Windows Desktop chatgpt-thread reopen/scroll path.