[FEATURE] Automatic `gh pr view` polling bypasses the permission system and cannot be disabled

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Summary

Claude Code's built-in "PR review status" feature executes gh pr view --json number,url,reviewDecision,isDraft,headRefName,state as a direct subprocess every ~60 seconds. This execution bypasses the permission system and cannot be disabled through any setting, environment variable, or CLI flag. I believe this is a problem for two reasons: it undermines trust in the permission system, and it lacks the opt-out mechanism that other automatic features provide.

Permission system bypass

Claude Code provides a permission system that gives users control over what commands the tool can execute. However, the PR status polling spawns gh as a direct subprocess, outside of this system:

permissions.deny rules have no effect, because this is not a Bash tool invocation.
CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 has no effect, because this environment variable only controls the Bash tool's run_in_background parameter.
I think this is a problem because users who configure permission rules reasonably expect them to cover all external command execution. If there are exceptions, they should at least be documented.

Insufficient disclosure

The https://code.claude.com/docs/en/interactive-mode#pr-review-status describes this feature as follows:

"The status updates automatically every 60 seconds. PR status requires the gh CLI to be installed and authenticated (gh auth login)."

This tells users that gh is required, and that the status updates every 60 seconds. However, I don't think this is sufficient disclosure. It does not mention:

That gh pr view is executed automatically as a subprocess, outside of the permission system
That permissions.deny rules cannot block this execution
That there is no way to disable this behavior
A user reading this documentation would reasonably assume that the permission system still applies to all gh command execution. The gap between what is disclosed and how the feature actually works is, I believe, a problem worth addressing.

No way to opt out

Other automatic features in Claude Code have opt-out mechanisms:

Background tasks → CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1
Prompt suggestions → CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=false
PR status polling has no equivalent. I think there should be a way to disable it — whether through an environment variable or a setting — for consistency and to give users control.

Real-world impact

My environment uses a gh wrapper that requires interactive authentication for each invocation. The authentication credentials are cached for a short period for security reasons, but Claude Code's ~60-second polling interval exceeds this cache window.

As a result, every poll triggered a new interactive authentication prompt. This created an unending storm of authentication dialogs that made the tool unusable. Even running ls or cat (commands entirely unrelated to GitHub) appeared to trigger authentication prompts because the polling coincided with tool execution timing.

It took significant investigation effort to identify that the root cause was Claude Code's internal polling — precisely because this execution is invisible to the user and does not appear in tool call logs.

Environment

Claude Code v2.1.33
macOS (Darwin 25.2.0)
gh CLI installed via Homebrew, wrapped with an interactive authentication layer

Proposed Solution

Provide a way to disable PR status polling.
An environment variable (e.g., CLAUDE_CODE_DISABLE_PR_POLLING=1) or a setting (e.g., "prStatus": { "enabled": false }) would be sufficient.
Consider routing the execution through the permission system, so that users' deny rules are respected.
Document what the permission system does not cover. Specifically, disclose that the PR status feature executes gh outside the permission system and that there is currently no way to opt out.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

_No response_