Cloud sessions lost connected-account GitHub access overnight — repo reads now 403 demanding GitHub App org install, contradicting docs

Summary

Claude Code on the web cloud sessions (including scheduled routines) could read private-org repositories via the session's GH_TOKEN on Jun 30, matching the documented behavior. On Jul 1, identical read-only probes return 403 everywhere, with an error demanding a GitHub App org install. Either the /web-setup connected-account token binding regressed, or a policy change shipped that contradicts the current docs.

Docs vs. observed

The Claude Code on the web docs state:

With either method, a cloud session can access any repository the connecting GitHub account can see, not just the repositories the Claude GitHub App is installed on. App installation enables PR webhooks for Auto-fix; it is not a session-level access control.

Observed since Jul 1 (any session shape):

HTTP 403 — "GitHub access is not enabled for this session. An org admin must connect the Claude GitHub App for this organization."

Timeline

All times America/Chicago; same account throughout; /web-setup synced; org/repo names genericized (can share specifics privately).

| When | Environment | Probe | Result |
|---|---|---|---|
| Jun 30 21:27 | env_01WWga8… | curl -H "Authorization: Bearer $GH_TOKEN" https://api.github.com/repos/<org>/<private-repo> | 200, private: true; org-wide issue search also 200 |
| Jun 30 23:14 | env_01WWga8… | same read via gh api (gh 2.95.0) | 200, private: true |
| Jul 1 ~13:34 | env_012GAy… (scheduled routine; the repo was added to the session's Repositories) | gh api repos/<org>/<private-repo> | 403 (App-install message above) |
| Jul 1 (after re-running /web-setup twice) | env_012GAy…, no source repos | same curl | 403 ("…not enabled for this session. Use add_repo to request access.") |
| Jul 1 15:26 | env_01WWga8… (the env that returned 200 the night before; identical no-source probe) | same curl | 403 on the private repo, on a public repo in the same org, and on org-wide search |

Additional facts:

• GH_TOKEN inside every session is the literal sentinel string proxy-injected (both when access worked and when it didn't) — the real credential is applied by the egress proxy.
• gh api user succeeds throughout (returns the correct login), so an identity binding exists; only repo reads are gated.
• GitHub MCP tools in the same sessions still work, but direct reads are enforced against the session's Repositories allowlist ("Access denied: repository '…' is not configured for this session. Allowed repositories: …").
• Ruled out via controlled probes: source-repo binding (403 with and without sources), the specific environment (both environments affected), the session Repositories list (repo listed → still 403 via gh/curl), and stale token sync (/web-setup re-run twice on Jul 1).

Expected

Connected-account repo access per the docs (and per the observed Jun 30 behavior).

Actual

A hard GitHub-App org-install gate on all api.github.com repo reads through the proxy since Jul 1.

Ask

Is this an intentional policy change (if so, please update the docs quoted above), or a regression in the /web-setup connected-account token binding? Happy to share specifics — org name, account, environment/session IDs (e.g. probe sessions cse_01XtEhPRVQArpJucgnWaThDz, cse_01F9cMbSMR7VFvhiBK9e1uoD) — through a private channel if useful.