Remote routines on private GitHub repos auto-disabled with auto_disabled_repo_access after first run
Status Fixed / completed
Maintainer reply None cached
Activity 3 comments · opened Jun 3, 2026 · closed Jun 5, 2026
Describe the bug
Scheduled remote routines (/code/routines) that target a private GitHub repository are repeatedly auto-disabled with ended_reason: "auto_disabled_repo_access" immediately on first fire, even when the routine ran successfully on a prior session.
To reproduce
- Create a remote routine targeting a private GitHub repo
- Routine fires, runs, and completes successfully
- Routine is subsequently auto-disabled (
enabled: false,ended_reason: "auto_disabled_repo_access") - Re-enabling via API restores it, but it dies again on the next fire
Observed pattern
- Affects 3 of 4 routines targeting the same private repo
- The 4th routine has been healthy for 5+ days — it was re-enabled earlier and appears to have cached credentials
- The 3 affected routines die within minutes of firing — before any
git push, confirming the failure is at repo checkout (read), not push (write) - One routine explicitly does no git push, yet still dies — rules out write access as the cause
- No new commits appear in the repo from failed runs, confirming nothing executes
Expected behavior
Routines should maintain repo access across fires without requiring manual re-enable.
Environment
- Claude Code remote routines (CCR)
- Environment:
env_014srqQBonPPddvGcLwVryun(Anthropic Cloud, Default) - Repo visibility: private
3 Comments
Thanks for the report!
Can you try re-authorizing github in your settings?
We've improved errors here so you should see a more detailed error next time this occurs.
I've been looking for these specific settings to no avail on either my repo or Claude. I disconnected GitHub from my claude customize section, but when I regranted access, there were no prompts to select anything different. Looking on GitHub under authorized apps, there isn't an option to modify permissions for Claude. Is there a way to reset the authorization page and try again? Or should I be looking somewhere else? Thanks.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.