Describe the feature or problem you’d like to solve

AI coding agents (Copilot, Claude Code, Cursor, etc.) need GitHub access via gh to create branches, push commits, and open PRs. But gh auth login authenticates as the full user — so any process with access to the token can operate across every repo you have access to with full permissions.

This is a real problem when running AI agents. An agent scoped to work on one repo can read, write, or merge across all your repos. But if you don't authenticate at all, the agent becomes pretty useless and you're constantly stepping in to do things manually.

Fine-grained PATs partially solve this — they support per-repo and per-permission scoping — but they need manual creation and rotation outside the gh flow, and they're themselves one of the main things being stolen by malicious packages right now. Token exfiltration from env vars and config files is one of the most common supply chain attack vectors.

MCP servers are another option but they come with their own problems. Most AI agents default to the gh CLI first — it's what they know and it's already there. MCP servers often need PAT tokens anyway, so you're back to the same theft risk. They also add another dependency and integration layer that can break, and not every agent runtime supports them. For most setups, gh is the path of least resistance, so it makes sense to make that path safer.

Proposed solution

Allow gh auth login to accept repo and permission constraints that are enforced locally by the CLI. That way processes using gh (including AI agents) can't exceed the boundary you set, even if the underlying credential has broader access.
Something like:

gh auth login --scope-repo owner/repo-name

# Restrict with specific denials
gh auth login --scope-repo owner/repo-name --deny merge,delete

# Multiple repos
gh auth login --scope-repo owner/repo-a --scope-repo owner/repo-b

The CLI would filter or reject API calls outside the declared boundary before they hit GitHub's API. This doesn't replace branch protection or fine-grained PATs — it's a local boundary for the common case of handing gh access to an agent

Additional context

The main use case is AI coding agents that need push/PR access to a specific repo but shouldn't be able to touch anything else. This is basically the same idea as Docker's --read-only or git safe.directory — a local constraint on top of existing credentials.