Conversation history temporarily blocked by “Too many requests” during normal ChatGPT use

Open 💬 4 comments Opened Aug 15, 2026 by ChrisZhangWG
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

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.

<img width="1310" height="726" alt="Image" src="https://github.com/user-attachments/assets/0edb872e-6800-491e-9fc6-32f5af001540" />

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 12 days ago

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

  • #38503
  • #37518

Powered by Codex Action

kendonB · 7 days ago

Also seeing this in a fresh browser session

<img width="932" height="342" alt="Image" src="https://github.com/user-attachments/assets/7c5484e3-0147-41f9-b0d3-ddb6f7fe7455" />

my list of chats isn't displaying so this could be chat enumeration hammering the server

Rinne-n · 4 days ago

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.
  • This differs from #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 · 1 day ago

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.