You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Conversation history temporarily blocked by “Too many requests” during normal ChatGPT use #38763
While using ChatGPT normally in Chrome, I received the following modal:
Too many requests
You’re making requests too quickly. We’ve temporarily limited access to your conversations to protect your data.
Please wait a few minutes before trying again.
The restriction blocked access to conversation history itself, rather than merely limiting model messages or usage. It interrupted an active workflow and prevented me from opening the relevant chat.
I was not deliberately sending automated, bulk, or high-frequency requests. The issue appeared during normal interactive use.
Why this is concerning
The message does not clarify:
which type of request triggered the restriction;
whether the limit applies to the current browser session, account, or conversation-history endpoint;
how long the restriction will last; or
whether ordinary navigation, sidebar refreshes, or opening conversations can contribute to it.
This looks similar to reports of repeated /conversations 429 responses and temporary conversation-access restrictions, including issues #37518 and #38503.
Expected behavior
Normal use of ChatGPT—including opening chats and navigating conversation history—should not trigger a temporary block on conversation access. If a history-related endpoint is rate-limited, the UI should distinguish it from a model-usage limit and apply sensible retry/backoff behavior.
Environment
Surface: chatgpt.com in Google Chrome on macOS
Subscription: ChatGPT Pro
Screenshot: attached
Date/time: 2026-08-15, Hong Kong time
Additional information
The problem resolved only after waiting, but it disrupts ongoing work and risks making conversation context temporarily unavailable.
Same symptom, but persistent rather than intermittent
Symptom
GET /backend-api/conversations?offset=0&limit=28&order=updated returns 429, so the conversation list never loads. The UI shows a modal reading: "Too many requests — You're making requests too quickly. We've temporarily limited access to your conversations to protect your data. Please wait a few minutes before trying again."
Observations
The 429 occurs on a single request. There is no retry storm and no parallel burst — one request, immediately rejected.
Response time is ~800 ms, so this is an immediate rejection, not a timeout or a slow/failing query.
It is rejected at offset=0, i.e. the first page. This suggests the behaviour does not depend on the total size of the conversation history.
It also occurs immediately after opening a new chat. No automation, bulk operations, or rapid successive requests were involved.
Client asymmetry
Reproduces in the web app (Chrome) and in ChatGPT Classic.
Codex retrieves and displays the same conversation list for the same account without any problem.
Opening a conversation by direct URL works fine, so the underlying conversation data is intact.
Duration
Continuous since July 9, 2026 — the day the Codex app was merged into the ChatGPT desktop app. I have been on the new app since day one. The modal says "wait a few minutes," but the condition has not cleared in over six weeks.
I disabled the GPT-related Chrome extension the previous evening. The issue
did not resolve immediately, but by the next morning the conversation
history was loading normally again.
One correction to my earlier observation: when I said no automation was
involved, that was accurate for my own actions. However, I cannot rule out
background traffic generated by a browser extension, which would not
necessarily appear in the page's own DevTools Network panel.
If anyone else encounters the same issue, disabling Chrome extensions may be
worth trying.
I am also affected by the conversation-access restriction on a Pro account, continuing through September 27, 2026.
In my case, during the blocked periods it is not just the history list: every conversation I try to open can fail, and a conversation that has briefly displayed its contents can revert to "Could not load this ChatGPT conversation". Leaving tabs open has not kept them usable. Earlier access blocks lasted roughly 10–20 minutes at a time, and the issue has persisted into the next morning, blocking my work.
My own report is #48683, with the exact visible symptoms and a description of a recording. I cannot confirm whether this is the same cause as the extension-related case above; there is no captured HTTP status for my recording. Please link this evidence to the active investigation and clarify the recovery path for accounts still affected.
Activity
github-actions commentedon Aug 15, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
kendonB commentedon Aug 20, 2026
Also seeing this in a fresh browser session
my list of chats isn't displaying so this could be chat enumeration hammering the server
Rinne-n commentedon Aug 23, 2026
Same symptom, but persistent rather than intermittent
Symptom
GET /backend-api/conversations?offset=0&limit=28&order=updated returns 429, so the conversation list never loads. The UI shows a modal reading: "Too many requests — You're making requests too quickly. We've temporarily limited access to your conversations to protect your data. Please wait a few minutes before trying again."Observations
Response time is ~800 ms, so this is an immediate rejection, not a timeout or a slow/failing query.
It is rejected at offset=0, i.e. the first page. This suggests the behaviour does not depend on the total size of the conversation history.
It also occurs immediately after opening a new chat. No automation, bulk operations, or rapid successive requests were involved.
Client asymmetry
Codex retrieves and displays the same conversation list for the same account without any problem.
Opening a conversation by direct URL works fine, so the underlying conversation data is intact.
Duration
Continuous since July 9, 2026 — the day the Codex app was merged into the ChatGPT desktop app. I have been on the new app since day one. The modal says "wait a few minutes," but the condition has not cleared in over six weeks.
This differs from ChatGPT on the web: “Too many requests” blocks chat access and disrupts Work tasks #38503, where access is restored after waiting and the problem is intermittent. In my case the restriction appears to be stuck rather than transient.
Rinne-n commentedon Aug 26, 2026
Update — Aug 26, 2026
The issue is now resolved.
I disabled the GPT-related Chrome extension the previous evening. The issue
did not resolve immediately, but by the next morning the conversation
history was loading normally again.
One correction to my earlier observation: when I said no automation was
involved, that was accurate for my own actions. However, I cannot rule out
background traffic generated by a browser extension, which would not
necessarily appear in the page's own DevTools Network panel.
If anyone else encounters the same issue, disabling Chrome extensions may be
worth trying.
tapperwijn89 commentedon Sep 27, 2026
I am also affected by the conversation-access restriction on a Pro account, continuing through September 27, 2026.
In my case, during the blocked periods it is not just the history list: every conversation I try to open can fail, and a conversation that has briefly displayed its contents can revert to "Could not load this ChatGPT conversation". Leaving tabs open has not kept them usable. Earlier access blocks lasted roughly 10–20 minutes at a time, and the issue has persisted into the next morning, blocking my work.
My own report is #48683, with the exact visible symptoms and a description of a recording. I cannot confirm whether this is the same cause as the extension-related case above; there is no captured HTTP status for my recording. Please link this evidence to the active investigation and clarify the recovery path for accounts still affected.