CCR routine sessions can't reach GitHub — outbound traffic appears routed through a broken internal proxy

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?

Scheduled Claude Code routines (CCR) in my account cannot reliably clone or push to a private GitHub repo, even when given a verified, fully-valid credential. The sandbox appears to route outbound GitHub traffic through some internal proxy/credential layer that overrides or interferes with the token supplied in the routine's own script, rather than using it directly

What Should Happen?

A routine should be able to use the GitHub credential provided in its own script (e.g. a PAT in a git clone https://TOKEN@github.com/... URL, or a direct Authorization header in an API call) and reach the target repo successfully, the same way it would from any normal machine with that token

Error Messages/Logs

Every attempt — scheduled and manual — fails at the repo-access step with 403/404, and the routine reports the credential as broken. But the credential is not broken: I independently verified it from outside the sandbox each time and it worked.

Steps to Reproduce

Generate a brand-new GitHub PAT (classic, repo scope) for a private repo.
Verify it externally — e.g. curl -H "Authorization: token <PAT>" https://api.github.com/repos/<owner>/<repo> → returns 200 OK with full repo data.
Put that token into a CCR routine's script (e.g. git clone https://<PAT>@github.com/<owner>/<repo>.git).
Trigger the routine (scheduled or manual run) within the same minute as step 2.
Observe the routine fail at the clone/API step with 403/404.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.183

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Across roughly 5 attempts (scheduled + manual) over several hours, the routine reported three different, mutually inconsistent diagnoses for what looks like the same underlying failure:

A hardcoded git insteadOf rule redirecting github.com URLs through a local credential proxy, overriding the supplied token.
The token authenticating but having "zero OAuth scopes."
The token authenticating but the account showing "zero repos visible," with the target repo returning 404.
One run explicitly stated outbound traffic is routed through "a pre-configured proxy." Since the identical token worked every time when tested from outside the sandbox, I believe the sandbox's network egress/credential-handling for GitHub is broken or misconfigured, independent of whatever token is supplied.