Desktop app's GhRestClient burns the user's GitHub GraphQL rate limit: ~640 points per session focus, ~2,000 per turn start

Summary

The Claude Code desktop app (macOS) makes very large bursts of GitHub GraphQL API calls through its internal GhRestClient, authenticated as the user, and exhausts the user's personal 5,000 points/hr GraphQL rate limit within minutes of normal use. Measured costs:

• ~640 points for a single session focus in the sidebar (setFocusedSession / preview warm-up)
• ~1,970 points for sending one message / starting a turn
• windows repeatedly reach 10,000+ used (2× the limit, indicating high parallelism)

Because GitHub's GraphQL limit is per-user across all tokens, this starves everything else that shares the identity: gh CLI in sessions (a plain gh pr checks costs 1 point), the GitHub MCP server, and the app's own CI widgets — sessions then see "GitHub API rate limit exceeded (5,000/hr shared across all tools and agents)" and CI watchers fail silently. Likely related symptom: #78222.

Environment

• Claude desktop app 1.32885.1 (macOS, Darwin 25.5.0), Claude Code CLI 2.1.234
• ~30 local sessions in one project over recent days; the app has ~38 session↔PR bindings across 5 repos (log shows 648 LocalSessions.getPrChecks entries, prNumber, dismissBoundPr)

Evidence

~/Library/Logs/Claude/main.log — the app's own GraphQL client hitting the wall repeatedly since Aug 18:

2026-08-18 17:55:29 [warn] [GhRestClient] GraphQL errors { '0': { type: 'RATE_LIMIT', code: 'graphql_rate_limit', message: 'API rate limit already exceeded for user ID 3220689.' } }
2026-08-18 19:57:11 [warn] [GhRestClient] GraphQL errors { ... }
2026-08-19 21:42:12 [warn] [GhRestClient] GraphQL errors { ... }
2026-08-20 08:30:14 [warn] [GhRestClient] GraphQL errors { ... }

Controlled measurement (sampling gh api rate_limit --jq .resources.graphql.used every 10–15s, correlated with main.log timestamps and lsof snapshots showing only the Claude process holding GitHub TCP connections at spike time):

• Fresh window at 12:47:41 → used=0
• 12:49:02 log: setFocusedSession on an idle session → 12:49:12: +640 points
• 12:49:26 log: sendMessage to that session → 12:50:59: +1,970 points (plus +310 at 12:51:15 as the turn spun up)
• With all sessions idle and no UI interaction, usage is flat (~2 points/min) — the burst is entirely UI/turn-event driven

Ruled out by measurement during the same investigation: user shell commands (each gh pr checks/view/list = 1 point), SessionStart hooks (0 points), CI workflows (repo-scoped tokens; no runs during bursts), cron/launchd jobs, OAuth apps (GitHub settings show only GitHub CLI recently used), and the cloud "Autofix pull requests" feature (bursts continue with it disabled and correlate with the local process).

What did NOT mitigate it

• Archiving finished PR-bound sessions (burst quantum unchanged at ~640 → fan-out appears not proportional to active session count)
• Disabling claude.ai → Settings → Claude Code → "Autofix pull requests"

Expected

Session focus / turn start should cost O(1–10) GraphQL points (one PR + checks query for the focused session), be cached/debounced, and degrade gracefully — not fan out to every tracked PR binding in parallel and consume a day's practical quota in minutes, and not double-spend past the limit.

Impact

Any user running multiple PR-attached sessions loses their entire GitHub GraphQL quota to the app shell, which then breaks gh-based workflows inside their sessions (merge queues, CI watchers) in ways that look like GitHub flakiness. Workaround we've adopted: run GitHub-heavy sessions from a plain terminal, where the desktop shell's poller is not present.