[BUG] Web session on a fork can't read upstream's public issues via the repo-scoped API; suggested add_repo refuses cross-owner adds

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?

A web session rooted at a fork (say chrisbobbe/zulip-flutter) can't read the upstream repo's public issue tracker (zulip/zulip-flutter) through the GitHub API's repository endpoints: the GitHub proxy rejects repos/{upstream}/... requests, authenticated or not. This affects the built-in list_issues/issue_read tools, which are repo-scoped. The proxy's error message says to use add_repo, but add_repo refuses repos from a different owner: "cross-tier adds are not supported in v1". Full error text below.

The repo-scoping itself is documented: "The proxy limits GitHub API and release-asset requests to repositories attached to the session, regardless of the environment's network access level". But the same docs promise built-in tools that "let Claude read issues, list pull requests, fetch diffs, and post comments without any setup", much of which a fork-rooted session cannot do for the tracker its work comes from.

That limit holds only at the API, though: other routes reach most of the same data. All of the following were tried from a single fork-rooted session, against the upstream repo:

| Route | Result |
| --- | --- |
| api.github.com/repos/{upstream}/... (unauthenticated curl) | 403, "use add_repo" |
| api.github.com/search/issues, called directly (curl/gh) | 403, "sessions are bound to their configured repositories" |
| built-in list_issues / issue_read, owner={upstream} | denied, "repository not configured for this session" |
| built-in search_issues / search_pull_requests, repo:{upstream} in the query | works, though direct search/issues calls are 403'd; returns issue/PR bodies |
| git ls-remote / git fetch of upstream, including pull/N/head refs | works; full code and PR diffs |
| curl → raw.githubusercontent.com/{upstream}/... | works (documented: served via the security proxy's Trusted list) |
| curl → github.com/{upstream} HTML, codeload, patch-diff | 403, at the egress proxy |
| WebFetch → github.com/{upstream} issue/PR/search pages | works; the same URLs 403 via curl, so WebFetch evidently fetches from outside the sandbox |
| WebFetch → api.github.com, or a PR .diff (redirects to patch-diff) | 403 |

(We also tried gh, which our environment's setup script installs; it wraps the same API and fails identically.)

The docs offer an escape hatch: a user-set GH_TOKEN "passes through to the container unchanged, so gh and your scripts use it directly". In fact a read-only PAT changed no row above; the proxy applies the same limits regardless of who's authenticating. The token does reach GitHub on unscoped paths (gh api user returns the authenticated profile), yet gh auth status calls it invalid. And a third error appears on the session's own repo: repos/{fork}/... fails with "GitHub access is not enabled for this session. An org admin must connect the Claude GitHub App for this organization", said of a personal fork. (This session connects GitHub via OAuth, not an App install; App sessions may fare better on their own repo. The upstream rows don't depend on the auth method.)

In practice the model tries the blocked API paths first, then reassembles the data from the routes that work. The session guidance compounds this by directing search_issues/search_pull_requests (the only API-backed route above that reaches upstream) away from repos outside the session's scope.

The one thing no route reaches is issue comments. The comments API is blocked; search results don't include comment bodies; and WebFetch of an issue page returns only the issue body, with no comments in the HTML as served (the issues UI appears to load them client-side; PR pages do serve their conversations). For a session implementing an upstream issue, the comment thread is often where the spec got worked out.

The available workaround, starting a separate session on upstream just to read issues, has its own cost: sessions push branches to their root repo, so a contributor with upstream push access risks stray working branches landing there.

What Should Happen?

A fork-rooted session can read the upstream repo's public issues and PRs, comments included, through the documented tools. Any of:

1. the documented repo limit is relaxed to pass read-only GitHub API requests for public repos; or
2. add_repo supports cross-owner adds with read-only scope (the interactive approval prompt already exists); or
3. at minimum, the proxy error stops advising add_repo for a repo that add_repo cannot add.

Separately, a user-set GH_TOKEN should either work as documented or the docs should say what the proxy does with it.

(The built-in search_issues/search_pull_requests are today an undocumented exception to the documented repo limit. Consistency there would be welcome too, but closing the exception without one of the above would just remove the only API route that works.)

Error Messages/Logs

$ curl -sS 'https://api.github.com/repos/zulip/zulip-flutter/issues?per_page=1'
{"message":"GitHub access to this repository is not enabled for this session. Use add_repo to request access.","documentation_url":"https://docs.anthropic.com/en/docs/claude-code/github-actions"}

add_repo (owner: zulip, repo: zulip-flutter), after approving the permission prompt:
cross-tier adds are not supported in v1: requested "zulip/zulip-flutter" but session already has repos from owner(s) [chrisbobbe]. Start a new session with the requested repo as the initial source, or add a repo from the same owner as the existing sources

via gh, which wraps the same API (identical with and without a user-set read-only PAT in GH_TOKEN):
GET repos/zulip/zulip-flutter/...: HTTP 403, "use add_repo to request access"
GET search/issues: HTTP 403, "This GitHub API path is not available: sessions are bound to their configured repositories. Use repository-scoped endpoints (repos/{owner}/{repo}/...)."
GET repos/chrisbobbe/zulip-flutter/... (the session's own repo): HTTP 403, "GitHub access is not enabled for this session. An org admin must connect the Claude GitHub App for this organization."
GET user (with the PAT): HTTP 200, authenticated profile -- while `gh auth status` reports "The token in GH_TOKEN is invalid."

built-in GitHub tool list_issues / issue_read (owner: zulip, repo: zulip-flutter):
Access denied: repository "zulip/zulip-flutter" is not configured for this session. Allowed repositories: chrisbobbe/zulip-flutter

Steps to Reproduce

1. In Claude Code on the web, start a session on a personal fork of an org repo.
2. Run curl -sS 'https://api.github.com/repos/<upstream>/issues?per_page=1'. The proxy intercepts it, saying to use add_repo.
3. Have Claude call add_repo for the upstream repo, and approve the prompt. It fails: cross-tier adds not supported.
4. Have Claude call the built-in list_issues or issue_read tool for the upstream repo. Denied.
5. Have Claude call search_issues with repo:<upstream> in the query, or run git fetch <upstream-url> pull/<n>/head, or WebFetch the issue's github.com URL. These all work.
6. Ask for the comments on an upstream issue that has some. Nothing reaches them: the API paths are blocked, and WebFetch returns the issue body without comments.
7. Optionally, set GH_TOKEN to a read-only PAT per the docs and repeat step 2: identical result. gh api user succeeds (the token is valid and reaches GitHub) while gh auth status calls it invalid.

Claude Model

Other (Fable 5)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.211

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Related issues:

• #57641 asked for this in May 2026; one of its scenarios is "triaging a public issue tracker for a project I contribute to but don't own". It got no maintainer response: an auto-triage bot proposed duplicates, the author rebutted them, and a stale-bot closed it on 2026-07-07, inviting a new issue if still relevant.
• #23627 (open) asks for full multi-repo support in web sessions, which would subsume this. But this issue is narrower: read-only access to public data. Resolutions 1 and 3 change only proxy policy and an error message, not the session model.
• #11139 (open) is nominally about permission-mode denials of gh in web sessions; its thread carries the longer history of GitHub access there, including the built-in tools' arrival in March, now documented under "Work with GitHub issues and pull requests".

The route matrix above was gathered by Claude Code itself (Fable 5), working inside such a session.