claude-code - 💡(How to fix) Fix PR-status polling exhausts GitHub GraphQL rate limit on repos with many open PRs

What happened: With a repo that has ~28 open PRs, Claude Code's inline PR-status feature repeatedly exhausts the GitHub GraphQL API rate limit. I see the banner: "GitHub API rate limit reached. Pull request status may be out of date until the limit resets." It recurs throughout the day — the GraphQL bucket resets hourly and is re-exhausted shortly after.

Evidence: gh api rate_limit shows the graphql resource at remaining: 0 (used well over the 5,000-point/hr cap) while core (REST) stays healthy (~3,700+ remaining). So it's specifically the GraphQL bucket, consistent with PR-status polling.

Reproduction: Single Claude Code session (confirmed it happens with one session — not a multi-session multiplier), authenticated gh, repo with ~28 open PRs. The poller appears to query PR status broadly across all open PRs rather than just the current branch.

Impact: PR-status display goes stale. It doesn't block git push/pull or REST gh calls, but it's persistent and noisy, and it consumes the shared per-user GraphQL budget that other tooling also needs.

Requested fix (any one would resolve it):

1. A setting to disable the PR-status poller (settings.json or env var), and/or
2. Throttle its poll frequency, and/or
3. Scope it to the current branch/worktree's PR(s) instead of all open PRs, and/or
4. Make it rate-limit-aware (back off when the GraphQL budget is low).

Environment: Claude Code CLI (macOS), GitHub personal account (5,000/hr GraphQL limit).

Possibly related: #59647 (PR status badge shown in every session's composer, not just the session that created the PR) and #62928 (PR monitoring routine) appear to stem from the same unscoped-polling behavior. Scoping the poller to the current branch/session — fix option 3 above — would likely address all three.