[BUG] No way to attach a public repository for read-only API access: read is gated behind push

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

From a cloud session there is no supported path to read the issues of a public
repository you do not own. add_repo with access:"read" does not attach the
repository, and the only mode that does attach it, access:"push", requires write
permission that nobody has on someone else's repository. A read-only capability
is therefore gated behind a write permission.

The chain:

1. GitHub API requests reach only repositories attached to the session

(documented under "Repository scope").

1. add_repo with access:"read" attaches nothing. It confirms that anonymous git

clone works, which does not include issues, and then directs the user to
access:"push".

1. access:"push" is the only mode that attaches, and it is refused for lack of

push access.

1. On a third-party public repository, push access is not obtainable. So there

is no path.

Step 2 explicitly directs the user to access:"push". Step 4 shows that for this
case push can never be granted. The tool recommends an action that it then
refuses for the only situation in which the recommendation is reached.

On the permission model: read and write are independent permissions, not two
steps on one ladder. Public repositories grant read without write, and
write-only drop directories are an established pattern in the other direction.
By making attachment the only route to API reads, and push credentials the only
route to attachment, the implementation collapses both onto a single axis and
makes the stronger permission a precondition for the weaker one. The most common
case, read but not write, has no representation.

The data in question is public. It is readable in any browser with no account
and no token. A read-only fine-grained PAT with Public Repositories access is
also refused, because the restriction is applied before the credential is
considered: /user and /rate_limit return 200 with the same token, while every
/repos/ and /search/ request returns 403.

What Should Happen?

access:"read" should attach a public repository such that read-only GitHub API
requests to it succeed, without provisioning write credentials.

Failing that, the message in step 2 should not direct users to a mode that
cannot be granted for the case at hand, and should state what the actual options
are.

Error Messages/Logs

add_repo with access:"read":

  Read access to `owner/repo` is already available: it is a public repository
  and this session's git proxy serves anonymous git reads (clone/fetch) of
  public GitHub repositories directly. Nothing was attached to the session.
  [...]
  GitHub API tools (issues, pull requests, the github MCP server) and
  register_repo_root do not cover unattached repositories. For any of those,
  call add_repo again with access:"push" to attach the repository with
  credentials.

add_repo with access:"push":

  add_repo: you need push access to owner/repo for Claude to make changes there

Subsequent API request:

  GET https://api.github.com/repos/owner/repo/issues   -> HTTP 403
  {"message":"GitHub access to this repository is not enabled for this session. Use add_repo to request access. ..."}

With the same fine-grained PAT:

  GET https://api.github.com/user         -> HTTP 200
  GET https://api.github.com/rate_limit   -> HTTP 200

Steps to Reproduce

1. In a cloud session, call add_repo for a public repository you do not own,

with access:"read". Observe that nothing is attached and that the response
directs you to access:"push".

1. Run: gh api repos/{owner}/{repo}/issues

Observe HTTP 403 from the GitHub proxy.

1. Call add_repo for the same repository with access:"push". Observe the refusal

for lack of push access.

1. There is no remaining option. The same request from a local Claude Code

session on the same account and the same credential succeeds and returns the
issue normally.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Not a client version regression: the change is server side. Read-only GitHub API access from cloud sessions worked on 2026-10-05 and failed on 2026-10-06.

Claude Code Version

2.1.300 (Claude Code) in the cloud session, 2.1.285 (Claude Code) locally, where the same requests succeed

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

Affects both the browser cloud session and the Claude Code web environment.
Local Claude Code sessions are unaffected and reach the same endpoints normally
with the same credential, which places the restriction in the cloud session
proxy rather than in GitHub, the token, or Claude Code itself.

The practical effect for me: I maintain a cross-project register of issues and
feature requests for the infrastructure I run, and verify issue status against
the API before acting on it. The remaining route, fetching the rendered issue
page, serves GitHub's anonymous cache. On 2026-10-06 it reported an issue as
open that had been closed on 2026-09-29.

Confirmed with Anthropic Support (conversation 215476262277724).

On the Terminal/Shell field: the defect occurs in a cloud session, which has no
interactive terminal. The session runs non-interactively on Ubuntu 24.04.5 with
bash, so "Non-interactive/CI environment" is the closest option in the list.

The network access setting does not affect this either, filed separately as #102317.