macOS app 26.803 refocus reloads Chat sidebar and triggers repeated conversation 429s
What version of the Codex App are you using (From “About Codex” dialog)?
26.803.41515 (build 6321)
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
macOS 26.5.2 (25F84)What issue are you seeing?
In the unified ChatGPT/Codex desktop app on macOS, the Chat conversation sidebar visibly reloads every time the app regains focus after switching from another application.
The sidebar briefly returns to a loading state instead of keeping the existing conversation list rendered. Repeated app switching makes the interface distracting and can leave the list waiting on retries.
A reproduced occurrence at 2026-08-08T00:22:04Z showed the focused primary renderer initiating four separate GET /conversations requests for overlapping sidebar variants. All four returned HTTP 429 with {"detail":"Too many requests"}, followed by retries at approximately one, three, seven, and eight seconds.
The request volume increased sharply after the app updated:
- Build 6321: 567 logged
/conversationsHTTP 429 responses over approximately 2 hours 42 minutes. - Previous build 6234: 74 logged
/conversationsHTTP 429 responses over approximately 21 hours 45 minutes.
The requests came from the focused primary renderer. I did not find evidence of an extra renderer window causing the duplication.
What steps can reproduce the bug?
- Open the ChatGPT/Codex desktop app and select Chat so the conversation sidebar is visible.
- Switch to another macOS application.
- Switch back to ChatGPT/Codex.
- Observe the conversation sidebar reload.
- Repeat the app switch several times. The sidebar reload occurs on each refocus, while local app logs show repeated overlapping
/conversationsfetches and 429 retries.
What is the expected behavior?
Refocusing the application should keep the current sidebar list rendered. Any freshness check should be deduplicated, run without resetting the visible loading state, and respect rate-limit backoff.
Additional information
- The regression began after the automatic update from 26.730.61639 (build 6234) to 26.803.41515 (build 6321) on August 7, 2026.
- The current app uses Chromium 151.0.7922.76; the previous build used 151.0.7922.71.
- No local sidebar or focus-refresh setting was found.
- Clearing local state has not been attempted because the logs point to focus-triggered request duplication and clearing state could destroy useful diagnostic evidence.
- Sanitized log excerpts can be provided privately to maintainers.
2 Comments
Confirmed on the official Linux desktop client as well. I think there is an additional request amplifier beyond the refocus behavior described in this issue.
Environment:
I initially reproduced the same account-level conversation-history rate limiting described here: the Desktop app starts receiving HTTP 429s from
/backend-api/conversations, and shortly afterwards the web ChatGPT UI for the same account also temporarily loses access to conversation history.While investigating, I locally disabled both:
refetchOnWindowFocusfor the normal and TPP conversation queriesThis removed the focus-triggered requests and the post-429 retry amplification, but the Desktop app could still hit 429 without any manual sidebar pagination.
The remaining trigger appears to be the Recents sidebar's automatic infinite-scroll pagination.
With a sufficiently tall sidebar viewport, I captured an
IntersectionObserverbecoming visible and immediately triggering successive conversation pages:IntersectionObserver intersecting=true
+12 ms -> /conversations ... limit=20&offset=40 200
IntersectionObserver intersecting=true
+2 ms -> /conversations ... limit=20&offset=60 200
IntersectionObserver intersecting=true
+2 ms -> /conversations ... limit=20&offset=80 200
IntersectionObserver intersecting=true
+3 ms -> /conversations ... limit=20&offset=100 200
No manual scrolling or pagination was performed.
Window height matters: with a short tiled window, the sentinel is quickly pushed outside the viewport and pagination stops. With a taller window, the sentinel can remain/re-enter the viewport and the client keeps loading additional pages automatically.
More importantly, after several pages had been loaded, I captured a later refetch/remount re-requesting the whole loaded page set:
t+0.00s offset=0 200
t+0.86s offset=20 200
t+1.79s offset=40 200
TPP limit=100 offset=0 200
t+3.01s offset=60 200
t+4.33s offset=80 200
t+5.74s offset=100 429
So one sidebar refresh can turn into 6 normal conversation-list requests plus the TPP request once the infinite query has accumulated enough pages.
Looking at the shipped frontend bundle, the Recents list explicitly uses an
infiniteScrollpagination mode backed byIntersectionObserver. The generic list component already also supports a non-automatic "Show more" button mode.This suggests the request amplification chain may be:
tall/under-filled sidebar viewport
-> automatic infinite-scroll pagination
-> more pages retained in the infinite query
-> later remount/refetch reloads all retained pages
-> conversation endpoint reaches 429
-> 429 retry behavior further amplifies the rate limit
So fixing only the refocus reload may not completely eliminate the problem.
Potential mitigations might be:
I had also encountered what appeared to be the same conversation-history rate limit previously with a repackaged macOS Desktop build, although I did not have detailed tracing from that occurrence. The Linux reproduction above is the one I traced in detail.
I can provide sanitized request logs / timestamps if they would be useful.
I also encountered this problem; switching the ChatGPT client to codex mode resolves it. This problem only occurs in ChatGPT mode.