[FEATURE] Let cloud sessions comment on public repos the user cannot push to

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

A cloud session can only reach repositories selected as its sources, and the source picker is populated by affiliation — repos you own, collaborate on, or are an org member of — which in practice means push access. It is not populated by visibility. So a public repository I can read and comment on perfectly well from a browser cannot be brought into a session at all.

The consequence: I filed #81502 and wanted Claude Code to watch it and help me respond to maintainer questions. It can't. GitHub itself imposes no such restriction — any authenticated user can comment on an issue in a public repo; no push access is required. The restriction is entirely on the Claude Code side.

(Closest existing request is #57641, but this is not a duplicate: that issue asked for read access and explicitly put writes out of scope — "Keep write operations (push, PR creation, comments) requiring App installation". This request is precisely that excluded case. See Additional Context.)

Evidence gathered from inside a cloud session:

| Path attempted | Result |
| --- | --- |
| Repo picker / repo listing | Every entry returns can_push: true. Public repos I'm affiliated with appear; unaffiliated public repos never do. A query for anthropic returns empty. |
| add_repo for anthropics/claude-code | cross-tier adds are not supported in v1: requested "anthropics/claude-code" but session already has repos from owner(s) [united-clouds] |
| GitHub MCP tools | Scope-gated to the session's sources; calls to any other repo are denied. |
| Direct API from the container | GH_TOKEN and GITHUB_TOKEN are both the literal placeholder proxy-injected. No usable credential exists in the container; git egress is a per-repo local proxy. |
| WebFetch on api.github.com | HTTP 403. |
| WebFetch on the issue's HTML page | Works — so I can read the issue by scraping rendered HTML, but cannot reply. |
| Forking to an owner I control | Forks don't carry the upstream repo's issues, so this doesn't reach #81502. |
| /web-setup (sync personal gh token) | Doesn't help. Every GitHub API that enumerates "your" repos returns affiliations only, so an unaffiliated public repo can never appear in that list regardless of token. |

Worth flagging as a possible documentation bug: the docs state that "a cloud session can access any repository the connecting GitHub account can see, not just the repositories the Claude GitHub App is installed on," and that App installation "is not a session-level access control." The observed behavior is considerably narrower — access tracks affiliation, not visibility. Either the docs overstate what's supported, or the picker is not honoring the intended model.

The net effect is that unattended workflows — watching an issue you filed on a public project, triaging an upstream bug, following a discussion in a dependency's tracker — are unavailable in cloud sessions, which is exactly where unattended work is supposed to live.

Proposed Solution

Let a session attach a public repository by slug with a read-and-comment scope, with no push access required.

1. Picker: add a free-text owner/repo field that resolves any public repo, alongside the existing affiliation list. Show attached-this-way repos with a clear read + comment badge so the reduced scope is visible.
2. add_repo: allow cross-owner adds when the target is public and the requested access is read-only. The current v1 same-owner restriction is the blocker for adding one mid-session.
3. Proxy scope for such a repo — authenticated as the user's own GitHub identity, mirroring exactly what GitHub already permits them to do:

• Allow: GET on repo contents, issues, PRs, comments; POST /repos/{o}/{r}/issues/{n}/comments.
• Deny: push, branch creation, PR creation/merge, labels, state changes, and anything else requiring elevated permission. These should fail with a clear "requires write access on {repo}" message rather than a generic denial.

1. Permissioning: off by default; explicit per-session opt-in. Posting a comment should be an approval-required action by default, since it's outward-facing and published under the user's name. The existing Claude Code attribution footer already marks such comments as Claude-authored.

Rate limiting is a solved problem here for the same reason #57641 gave: authenticating as the user moves requests from the shared-egress unauthenticated 60/hour to the user's own 5,000/hour budget.

Alternative Solutions

• Run the monitor locally where gh is authenticated as me. Works, but gives up cloud sessions and Routines entirely — unattended scheduled monitoring is the whole point, and a laptop that must stay awake defeats it.
• WebFetch scraping + hand-pasting replies. My current workaround: an hourly Routine scrapes the issue's HTML and drafts a reply I paste myself. Read-only by construction, and it breaks any unattended loop at the last step.
• Pre-fill URL (?repositories=owner/repo). Validates against the same affiliation list.
• Fork the repo. Forks don't carry upstream issues.
• Install the GitHub App on the repo. Not possible — I don't administer anthropics/claude-code, and this shouldn't require the App at all, since commenting on a public issue needs no elevated privilege.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

1. I file #81502 against anthropics/claude-code, a public repo I have no push access to.
2. I open a cloud session and attach anthropics/claude-code by slug as a read + comment source.
3. I ask Claude to watch the issue and set up an hourly Routine.
4. A maintainer comments asking which cloud provider I need first and whether a 15-minute token TTL is workable.
5. The Routine fires, Claude sees the new comment, drafts a reply grounded in the session's earlier context, and asks me to approve posting it.
6. I approve. The comment posts under my GitHub identity with the Claude Code attribution footer.

Today, step 2 fails and the rest is unreachable.

Additional Context

Relationship to #57641. That issue asked for read access to public repos via user OAuth and was closed as not planned — but it carries the stale label with no comments and no maintainer explanation, which reads as auto-closure for inactivity rather than a decision on the merits. It is also complementary rather than overlapping: #57641 scoped itself to reads and explicitly excluded comments. Both halves are needed for the workflow above, and I'd suggest reconsidering them together.

Related: #81502 (my OIDC request — the issue that motivated this).

One data point that may have changed since #57641 was filed in May 2026: that issue reported web_fetch as blocked in the cloud sandbox. In my session WebFetch against github.com HTML works fine, though api.github.com returns 403. So read access to public repo content is already partly reachable, just through the worst possible interface — HTML scraping instead of the API.

Prior art for the permission shape: GitHub's own model already draws this exact line. Comment-on-public-issue is available to every authenticated user; push is not. Adopting GitHub's boundary verbatim means no new policy surface has to be invented.

This request is co-authored with Opus 5.