›_ Codex Issues
Codex Issues / #36620

Codex App may rapidly consume GitHub GraphQL quota while resolving sidebar PR badges

Open 💬 2 comments Opened Aug 2, 2026 by comfuture

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App with bundled codex-cli 0.145.0 (the desktop client build is not exposed in this Linux environment)

What subscription do you have?

Unknown; the affected quota belongs to the separately authenticated GitHub user.

What platform is your computer?

Linux 5.15.0-1030-gcp x86_64 x86_64

What issue are you seeing?

Keeping Codex App open with many repository threads appears capable of consuming the GitHub user's shared 5,000-point GraphQL quota much faster than expected. I observed GraphQL usage reach 5006/5000 while REST core usage was only 120/5000, which caused other GitHub tooling to lose GraphQL access or fall back to REST.

The sidebar PR/merge badges are the main suspect. There is evidence in #25392 that the installed desktop bundle runs a gh-pr-status lookup using each thread's stored cwd and headBranch; intercepted traffic showed a GraphQL ISSUE_ADVANCED PR search with limit: 30. A follow-up there reports that every ordinary main-branch thread receives this lookup. #30476 independently confirms that PR status icons are rendered across sidebar thread rows.

The desktop UI implementation is not present in this repository, so I could not verify its refresh interval, caching, or deduplication. The public TUI path in codex-rs/tui/src/branch_summary.rs is different and does not establish desktop behavior. A short idle sample also did not show continuous consumption, so the drain may occur in bursts during app startup, thread restoration, or status refresh rather than from a fixed tight polling loop.

What steps can reproduce the bug?

  1. Authenticate gh and record gh api rate_limit --jq '.resources.graphql'.
  2. Open Codex App with many saved threads from GitHub repositories and allow sidebar PR badges to resolve, including after an app restart or thread refresh.
  3. Avoid manual gh commands that use GraphQL.
  4. Compare the GraphQL used count after the sidebar state has refreshed.

Please inspect whether gh-pr-status requests are issued once per thread without deduplication by repository/branch, and whether restored or inactive threads trigger repeated refreshes.

What is the expected behavior?

Sidebar PR status should be cached and deduplicated so an idle app or a large restored thread list does not materially consume the user's shared GitHub GraphQL quota.

Additional information

I searched for existing reports about Codex App, sidebar PR status, GitHub GraphQL, rate limits, and quota exhaustion. I found the related behavior reports #25392 and #30476, but no issue covering GraphQL quota consumption itself.

View original on GitHub ↗

2 Comments

ariiyu · 18 days ago

I encountered a similar symptom on macOS during normal Codex App usage.

On August 10, 2026, a user-initiated pull request finalization failed with:

GitHub’s GraphQL API rate limit was exceeded

The GraphQL quota was scheduled to reset at 13:43:37 JST. Retrying the same operation after the reset succeeded. REST API capacity was still available at the time.

Similar GraphQL-limit failures have occurred on separate occasions while I was working with different repositories.

My environment has a comparatively large number of saved Codex tasks across multiple repositories. I do not know whether the number of tasks, repository diversity, task restoration, or sidebar PR-status handling contributed to the quota exhaustion, but this may represent a different workload from an installation with only a few tasks and repositories.

A review of the locally available session history did not find:

  • a fixed polling loop;
  • gh pr checks --watch or an equivalent continuous watch command;
  • large-scale parallel GitHub activity; or
  • enough visible foreground GraphQL operations to explain consumption of the full 5,000-point quota.

However, the local history does not contain request-level GraphQL operation names, costs, or attribution between user-initiated and background requests. Therefore, I cannot confirm that sidebar PR badge resolution caused the exhaustion, or that Codex was the sole consumer of the shared quota.

I submitted the same occurrence through the in-app feedback form without attaching session or browser logs:

no-active-thread-019feab9-2325-7ba2-a8fe-30fb160ba38c

It may be useful to test Codex App startup, task restoration, and sidebar status resolution with a larger number of saved tasks and repositories, and to determine whether that workload can unexpectedly exhaust the shared GitHub GraphQL quota.

cubanx · 12 days ago

I reproduced this on Codex Desktop 26.810.41047 on macOS using 10-second samples from GitHub's authenticated GET /rate_limit endpoint.

Controlled comparison:

  • Codex closed: about 6 GraphQL points over roughly 9 minutes.
  • Reopen and restore existing tasks: 194 points in about 103 seconds.
  • Individual deltas were +75, +1, +63, +20, +32, and +3.
  • No instrumented custom GitHub workflow ran during that interval. The custom GraphQL operations I measured separately cost 1 point per successful invocation.

A longer 3h38m observation recorded 7,126 positive point deltas, including multi-thousand-point busy hours, while a later quiet full hour used only 39 points. This supports bursty startup/task-restoration/sidebar-refresh behavior rather than a constant tight polling loop.

GitHub does not provide retroactive per-caller attribution for the personal GraphQL bucket, so this is strong timing correlation, not proof of the exact internal operation. Logging GraphQL operation names and rateLimit.cost, then deduplicating/caching PR-status work by repository and branch, should make the source identifiable and reduce the drain.