[FEATURE] Claude Code on the web: allow read access to public GitHub repositories via user OAuth (no GitHub App install required)

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

Claude Code on the web (cloud sessions) currently injects only the first-party GitHub MCP, and that integration authenticates through the Claude GitHub App. The App must be installed on each account or organization whose repositories you want to use — even for public, open-access repositories.

This means there is no way today to point a cloud session at a public repo I don't own and haven't installed the App on. Common scenarios this blocks:

• "Look at how vercel/next.js handles X and explain it" — I can't run a session against the upstream repo.
• "Read torvalds/linux/Documentation/... and summarize" — same problem.
• Reviewing a public OSS dependency to debug an issue, without forking it first.
• Triaging a public issue tracker for a project I contribute to but don't own.

The fallback paths are also blocked. Per #23705, git clone, curl, and web_fetch against public GitHub URLs all fail in the cloud sandbox. And even where unauthenticated access nominally works, GitHub's primary rate limit for unauthenticated requests is 60/hour per IP — a limit that now applies to HTTPS clones and raw.githubusercontent.com downloads as well, not just REST calls. Since unauthenticated requests are bucketed by originating IP, every cloud session sharing Anthropic's egress IPs draws from the same 60/hour pool, which a single non-trivial agent workflow exhausts immediately.

Proposed Solution

When a user is signed in to claude.ai with a connected GitHub account (OAuth), Claude Code on the web should be able to read any repository that user can read on github.com — including public repositories owned by third parties — without requiring the Claude GitHub App to be installed on the owner.

Concretely:

• The cloud GitHub MCP should fall back from App-installation auth to the user's OAuth token for read operations on repos where the App is not installed. Authenticated requests get the user's full 5,000/hour rate limit instead of the shared 60/hour unauthenticated bucket.
• Write operations (push, PR creation, comments) can continue to require the App, since those legitimately need installation-scoped permissions on the target.
• Cloning a public repo into a cloud VM for read-only analysis should Just Work when the user pastes a public URL.

Why OAuth is the right layer: GitHub's permission model already distinguishes "what this user can see" from "what this app is installed on." Public repos are readable by any authenticated GitHub user without per-repo authorization. Gating that visibility behind App installation is stricter than GitHub itself requires and creates friction that doesn't exist in any comparable tool — Codespaces, gh CLI, VS Code, and Copilot Workspace all read public repos by user identity.

It also resolves the rate-limit problem: a user's OAuth token gets 5,000 requests/hour scoped to that user, instead of every cloud session sharing one 60/hour unauthenticated bucket per egress IP.

Acceptance criteria:

1. Logged-in user pastes a public repo URL they don't own into Claude Code on the web → session starts, repo is cloned, files are readable.
2. The first-party GitHub MCP exposes read tools (get file, list issues/PRs, read diffs) against that repo, using the user's OAuth token (5,000/hour limit), not unauthenticated access (60/hour shared).
3. Write tools either succeed (if the user has write access on GitHub) or fail with a clear "requires App installation" message — not a generic 403/404.

Out of scope:

• Private repos owned by third parties (correctly require explicit access).
• Write/push to repos the user doesn't have write access to on GitHub (correctly blocked by GitHub itself).
• Bypassing org SAML/IP allowlist restrictions.

Alternative Solutions

• Install gh CLI and provide personal access token for GH repos. Not secured.
• Require users to fork every public repo they want to read. Adds noise to their GitHub account, doesn't help with read-only exploration, and still requires installing the App on the fork.
• Require users to install the Claude GitHub App on every org whose code they want to read. Not possible — users don't have admin rights on vercel, torvalds, etc.
• Rely on the bash sandbox to git clone public URLs. Currently blocked (#23705); even if unblocked, would hit the 60/hour shared unauthenticated rate limit on Anthropic's egress IPs.
• Document the limitation and tell users to use the local CLI for public repos. Defeats the purpose of cloud sessions for any workflow that mixes the user's own repos with public dependencies.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

Related issues:

• #54441 — Cloud sessions don't load user-configured MCP servers; only the first-party GitHub MCP is injected. Establishes that the cloud GitHub MCP is the only path to GitHub data in web sessions.
• #23705 — Claude on the web cannot read, clone, or fetch source from public GitHub repos via bash/web_fetch. Confirms there is no fallback path.
• #11056 — Adjacent feature request about whitelisted private repo access for cross-repo dependencies.