Web sessions: add a mode "write access to every repo the GitHub token allows" (single source of truth for permissions)

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

Environment: Claude Code on the web (claude.ai/code), browser session, cloud container.
GitHub access: a GitHub PAT is configured in the environment properties.

Problem

Permissions end up defined in two independent places:

1. The GitHub token itself (its repository access and scopes) — the one I

maintain deliberately and consider authoritative.

1. The session's own repository list (chosen at session start, extendable

only one repo at a time via add_repo) plus the per-tool approval prompts.

Two filters over the same question ("what may the agent write to?") is a bad
practice: they drift apart, and the failure mode is confusing. The token says
"allowed", the session says "denied" (or asks for confirmation), and it is not
obvious which one to change.

In my session the token can write to many more repositories than the one
attached to the session. I do not know in advance which repositories a long
task will touch, so the work stalls at each new repository or approval.

What I tried

• The permission-mode dropdown next to the prompt box offers Accept edits /

Plan / Auto. There is no bypass-style mode, and the docs do not say whether
Auto covers MCP tool calls such as GitHub push / PR tools.

• Project .claude/settings.json is not read by cloud sessions, so a

project-level allow rule is not an option.

• I found no documented setting for "all repositories the connected GitHub

token/App can reach" as opposed to a per-session list.

Requested behaviour

An explicit opt-in mode (per environment or per session) meaning:
"The agent may write to any repository the configured GitHub token can write
to. Do not maintain a second allowlist and do not prompt for confirmation on
operations the token already permits."

The token's own permissions stay the only access-control definition. The mode
should be opt-in, visible in the UI, and revocable.

Why it matters

• One source of truth for permissions, managed where GitHub already manages it.
• Long autonomous tasks do not stall on approval prompts after a few minutes.
• No drift between the token's scope and the session's scope.

Related gaps in the docs

• Whether MCP tools (mcp__github__*) are covered by Auto mode.
• Whether a session's repository list can be derived from the token instead

of chosen manually.

Priority

Critical - Blocking my work

I have a large number of repositories, and I don't know exactly which ones I'll need while working on the task. Maintaining two lists—one in the GitHub token and one in Claude—creates two sources of truth; that’s a bad practice, and I’d definitely get confused. Besides, I have to maintain them in the token anyway.