Summary

Warp appears to make continuous GitHub GraphQL API calls from idle/inactive tabs, rapidly consuming the user's GitHub API rate limit (5,000 calls/hour). With many windows and tabs open, this can exhaust the quota in under 30 minutes even with no active sessions.

Environment

• Warp version: Latest (as of 2026-05-01)
• OS: macOS (Apple Silicon)
• GitHub auth: gh CLI authenticated via OAuth (gho_ token)
• Setup: ~12 Warp windows, ~12 tabs each. Tabs had previously been used for Claude Code, Codex CLI, and Gemini CLI sessions. Only 1 tab had an active session at the time of the drain.

Observed behavior

1. With Warp running on a second computer (~144 total tabs, mostly idle), GitHub GraphQL API rate limit was draining at ~2.4 calls/second (measured via gh api graphql -f query='{ rateLimit { used remaining } }' at 60-second intervals).

2. No other applications were making GitHub API calls — verified by:

   • Killing Chrome on both machines (no change in drain rate)
   • Confirming zero GitHub network connections from the primary machine via lsof
   • Confirming no gh CLI processes running
   • Confirming Docker containers were not the source (restarted Docker with no change)

3. Quitting Warp on the second computer immediately stopped the drain (rate went to 0.0/sec).

4. Reopening Warp fresh (with restored windows/tabs from previous sessions) caused an immediate burst of ~100+ GraphQL calls, then continued sustained polling at ~2/sec.

5. Important control: Warp was also running on the primary computer during the entire investigation with ~12 inactive tabs and 1 active tab — this instance did NOT cause any measurable drain. The difference was likely the number of tabs/windows or something about the restored session state on the second computer.

6. Reopening Warp a second time on the second computer (after previously quitting and clearing the session state) showed near-zero drain — suggesting the issue is tied to restored/stale session state rather than Warp itself.

Reproduction

Difficult to reproduce precisely, but the conditions were:

• Many Warp windows/tabs (~144 total)
• Tabs previously used with CLI tools that interact with GitHub (gh CLI, Claude Code, Codex CLI)
• Most tabs idle with no running process
• gh CLI authenticated to GitHub

Impact

At 2.4 calls/sec, the 5,000/hour GitHub GraphQL rate limit is exhausted in ~35 minutes. This blocks all GitHub CLI and API operations for the user across all devices and applications (rate limit is per-user, not per-device).

Diagnostic data

Rate measurements taken during investigation:

Questions

1. Does Warp poll GitHub APIs for repo/branch context on idle tabs?
2. Does session restoration re-trigger any GitHub API calls for previously active CLI sessions?
3. Is there a setting to disable or throttle GitHub API polling?
4. Are the GraphQL calls made using the user's gh OAuth token, or does Warp have its own GitHub integration?

Suggested fix

• Idle/backgrounded tabs should not make GitHub API calls
• If GitHub polling is needed, implement exponential backoff and respect the X-RateLimit-Remaining header
• Consider a per-session or global rate limiter for GitHub API calls