[Cloud sessions] Regression between 2026-06-18 and 2026-06-25: GitHub REST passthrough returns 403 "GitHub access is not enabled for this session" for org repos despite Claude GitHub App installed

Summary

Scheduled cloud routines (claude.ai/code triggers) that call the GitHub REST API directly (api.github.com/repos/<org>/...) worked every week from late April 2026 through Thursday 2026-06-18, then started failing on Thursday 2026-06-25 with a 403 emitted by the session's GitHub egress proxy:

{"message":"GitHub access is not enabled for this session. An org admin must connect the Claude GitHub App for this organization."}

Nothing changed on our side between those two dates (no changes to the routines' prompts, the cloud environment, or the GitHub org/app configuration). The Claude GitHub App is installed on the organization and has been for ~10 months.

Environment

• Claude Code on the web, scheduled triggers (/v1/code/triggers), 5 routines across 5 repos of the <org> GitHub org
• Cloud environment with the repo connected as a git source; git push and PR flows work fine
• Claude GitHub App installed on the org since ~Sept 2025, All repositories, permissions: read access to commit statuses/members/metadata; read-write access to actions, checks, code, discussions, issues, pull requests, repository hooks, workflows. No pending permission requests.

What works vs what fails (inside a cloud session)

| Call | Result |
|---|---|
| git push to <org>/<repo> | ✅ works (proxy credential) |
| curl -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/repos/<org>/<repo>/dependabot/alerts | ❌ 403 proxy message above (worked until 2026-06-18) |
| Same call with a user fine-grained PAT (security_events:read etc.) instead of the ambient token | ❌ same 403 — the proxy denies before considering the Authorization header |
| curl -H "Authorization: Bearer $GH_PAT" https://api.github.com/user | ✅ 200 (authenticated as the PAT owner) |
| curl https://registry.npmjs.org/ | ✅ 200 |

So the proxy selectively denies org-scoped REST paths (/repos/<org>/*) with an org-policy error, while non-org REST paths (/user, /rate_limit) pass through. The sandbox's /root/.ccr/README.md describes this as an egress-policy denial ("403/407 from the proxy: The destination host is not allowed by your organization's egress policy for this session").

Evidence of the regression window

Our routines create one PR per week per repo (branch security/YYYY-MM-DD, all created via POST /repos/.../pulls from inside cloud sessions):

• repo-a: PRs on 04-30, 05-07, 05-14, 05-21, 06-04, 06-11, 06-18 ✅ — then none
• repo-b: … 05-28, 06-04, 06-11, 06-18 ✅ — then none
• repo-c: … 06-11, 06-18 ✅ — then none
• repo-d, repo-e: same pattern

On 2026-06-25, all five runs aborted at preflight with the 403 above (transcripts available). Same on 2026-07-02/03.

What we tried (no effect)

• Supplying our own fine-grained PAT via environment variables (works for /user, still 403 on /repos/<org>/*)
• Reconnecting GitHub from claude.ai (no new authorization was requested)
• Verifying the org's OAuth app policy (no Claude OAuth app exists to approve — the integration uses GitHub App user authorization)
• Verifying the app installation for pending permission requests (none; permissions already include everything listed above)

Expected

Either the pre-June-25 behavior restored (org-scoped REST passthrough for sessions whose org has the Claude GitHub App installed), or documentation of what "connect the Claude GitHub App for this organization" concretely requires when the app is already installed — the error is not actionable as written.

Impact

Weekly automated Dependabot-triage routines across 5 repos are dead in the water; alerts are accumulating.