[ChatGPT Web] 429 recovery can lose exact /c/<id> binding and land on new/wrong conversation

What issue are you seeing?

On ChatGPT Web, opening or recovering an exact conversation URL can intermittently hit the “Too many requests” conversation-access limit and then fail to preserve the requested conversation identity through reload/recovery.

The observed failure is more specific than the generic history-rate-limit problem: after requesting an exact https://chatgpt.com/c/<conversation-A> URL, a 429/reload recovery can surface the root/new-chat composer instead of conversation A. In a multi-conversation workflow, this means navigation can appear usable again even though the originally requested conversation has not been restored.

I have also observed conversation-history reconciliation later making previously unavailable/finalized turns visible, so recovery code or a human operator cannot safely infer from the initial UI state alone that the requested conversation is absent, complete, or still generating.

The main safety/correctness concern is conversation identity loss: a retry/automation that treats “page loaded” as success could continue in a new or unintended conversation unless it independently proves the loaded conversation ID matches the requested /c/<id>.

I am not claiming that a message was actually sent to the wrong conversation; the defect creates that wrong-target continuation risk.

Steps to reproduce the bug

The behavior is intermittent rather than deterministic:

1. Have multiple long-running ChatGPT Web conversations open/active.
2. Navigate directly to an exact conversation URL, e.g. https://chatgpt.com/c/<conversation-A>.
3. Encounter the ChatGPT “Too many requests” / temporarily limited conversation-access state.
4. Reload or retry the exact conversation URL.
5. Observe that recovery can land on the ChatGPT root/new-chat composer rather than restoring conversation A.
6. Retrying/re-reading later may successfully expose the intended conversation/history again.

For a robust regression, also test recovery where the loaded URL/content identity does not match the originally requested conversation. That state should be treated as failed recovery, never as a successful target for a continuation send.

What is the expected behavior?

An exact /c/<id> navigation should retain that intended conversation binding across 429/backoff/reload/reconnect.

If the requested conversation cannot currently be loaded, ChatGPT should keep the target identity and show a bounded retry/error state. It should not silently convert the recovery into /, a new-chat composer, or another conversation.

Specifically:

• 429 should preserve the requested conversation ID and use bounded backoff;
• repeated 429s should not cause implicit conversation rotation;
• reload/reconnect should not count as successful recovery until the loaded conversation identity equals the requested identity;
• URL/content identity disagreement should fail closed;
• a new-chat composer after recovery should not be treated as the requested conversation;
• if a server-side response/history later becomes available after an apparent UI stall, the final result should be reconciled without duplicate continuation/resubmission.

Environment

• Surface: ChatGPT Web (chatgpt.com)
• Browser: Chromium-family desktop browser
• Date observed: 2026-09-09
• Workflow: multiple long-running conversations, direct /c/<id> navigation and reload/recovery

Private conversation IDs and transcript contents are intentionally omitted.

Related issues / why this is not just a duplicate

• #38763 reports normal ChatGPT Web use receiving “Too many requests” and losing temporary access to conversation history. This report adds the exact /c/<id> binding-loss/recovery-to-new-chat behavior and the resulting wrong-target continuation risk.
• #40745 reports a Windows beta desktop-app case where selecting an older conversation can leave the previously displayed conversation on screen. This report is specifically ChatGPT Web + exact URL navigation + 429/reload recovery.

If maintainers prefer #38763 as the umbrella tracker, please merge this evidence there, but the identity-preservation invariant should be tested explicitly.

No repository files or tests are named. Start at the ChatGPT Web exact /c/ navigation and 429/reload recovery paths; reproduce with a requested ID and verify recovery succeeds only when the loaded identity matches it, with bounded retries and no fallback to / or a new chat.