Cloud routine (RemoteTrigger) sessions: GraphQL API returns 403 for all queries, not just a 'pinned set'; REST calls also ignore the supplied GH_TOKEN

Summary

In a Claude Code cloud scheduled routine session (created via the RemoteTrigger//schedule API, i.e. claude.ai/code/routines), gh api graphql calls are rejected with:

{"message":"This GraphQL query is not enabled for this session — only the pinned set of PR-review operations is served. Use REST via `gh api repos/{owner}/{repo}/...` instead.","documentation_url":"https://docs.anthropic.com/en/docs/claude-code/github-actions"}

(HTTP 403, exit code from gh reflects the same message.)

This is not documented anywhere I could find — the documentation_url in the error points to the generic GitHub Actions setup page (https://docs.anthropic.com/en/docs/claude-code/github-actions, now redirects to https://code.claude.com/docs/en/github-actions), which does not mention this restriction, a "pinned set" of allowed operations, or GraphQL at all.

What I tested (all in the same routine session/environment)

1. gh api graphql -f query='query { viewer { login } }' → same 403, even though this is about as minimal a query as possible and has nothing to do with PR review.
2. gh api graphql -f query='query { organization(login:"...") { id login } }' → same 403.
3. gh api graphql -f query='query { repository(owner:"...", name:"...") { pullRequest(number: N) { reviewThreads(first: 5) { nodes { isResolved comments(first: 3) { nodes { databaseId body createdAt } } } } } } }' → same 403, even though this is literally a PR-review-related query (fetching review threads on a PR). This contradicts the "only the pinned set of PR-review operations is served" wording — if there is a pinned set, reviewThreads doesn't appear to be part of it, or the pinned-set carve-out doesn't actually apply to gh api graphql calls at all.
4. Supplying GH_TOKEN inline on the command vs. relying on a prior export GH_TOKEN=... made no difference — same 403 either way, confirming this isn't a credential/scope issue (also independently confirmed: the token in question is a classic PAT with repo, project, read:org, etc. — organization(login:...) with the same token works fine in a normal (non-routine) environment).
5. REST calls do not respect the supplied token value at all. gh api user --jq .login returns a fixed identity regardless of which token is passed via GH_TOKEN — including when passing an obviously invalid dummy string (e.g. GH_TOKEN=ghp_totally_invalid_dummy_value... gh api user still succeeds and returns the same login). This suggests the session's egress proxy substitutes its own credential for GitHub REST calls transparently, ignoring whatever GH_TOKEN/GH_BOT_TOKEN the agent sets.

Why this matters

• GraphQL is the only API for GitHub Projects (v2) — there is no REST equivalent for reading/writing project board items, status fields, etc. Any automation that needs to interact with a Projects v2 board from a cloud routine session is completely blocked, with no documented workaround.
• The error message's wording ("only the pinned set of PR-review operations is served") implies some GraphQL should work, which sent me down a debugging path (re-testing with correctly-scoped tokens, testing reviewThreads specifically since it's nominally a PR-review operation) that turned out to be a dead end — the restriction appears to be a full GraphQL block, full stop.
• The REST identity-substitution behavior (item 5) means any workflow that assumes "the account associated with the GH_TOKEN I set is who performs the API calls" is silently wrong in this environment. This is surprising and easy to miss (everything appears to work, just as a different identity than intended) — in our case it directly caused a bug where automated PR-comment replies posted under an unexpected identity, which broke an idempotency check that assumed a stable/known identity.

Request

• Documentation of this restriction (what's blocked, why, and what the intended workaround is) somewhere reachable — ideally the documentation_url returned in the error should actually point to a page describing it.
• Either: (a) clarify that GraphQL is fully blocked in these sessions (fix the misleading "pinned set" wording), or (b) actually allow the PR-review-related queries (like reviewThreads) the error message implies should work.
• Documentation of the REST identity-substitution behavior, so automation authors don't assume GH_TOKEN/custom PATs control which account performs REST calls in this environment.

Environment

• Claude Code cloud scheduled routine (RemoteTrigger API / claude.ai/code/routines), model claude-sonnet-5
• Reproduced across two separate one-off routine runs on the same environment