claude-code - 💡(How to fix) Fix Remote routines: manual Run now fails (HTTP 400) for any trigger with a git_repository source [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#56063Fetched 2026-05-05 05:59:09
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
Timeline (top)
labeled ×4commented ×1

Manual Run now (both web UI and POST /v1/code/triggers/{id}/run) fails with HTTP 400 for any remote routine whose session_context.sources includes a git_repository. The same triggers run successfully on schedule. Triggers without a git_repository source run successfully on manual invocation.

Web UI symptom: clicking "Run now" returns a toast that reads Failed to start run. You can try again.

Error Message

  • Body: {"type":"error","error":{"type":"invalid_request_error","message":"trigger_id: Extra inputs are not permitted"}} Manual Run now should kick off the routine for repo-tied triggers as it does for non-repo-tied ones. The trigger_id: Extra inputs are not permitted error message is also misleading — trigger_id is the path parameter, not a body field, so the validation message points users at the wrong thing. API rejects every manual run for repo-tied triggers with the same validation error. Scheduled fires for those same triggers complete normally (verified by past run history before triggers were updated). Result: there is no way to validate a repo-tied routine before its next scheduled fire.

Root Cause

A repo-tied trigger in my account auto-disabled itself with ended_reason: "auto_disabled_repo_access" shortly after creation, even with the user-level GitHub connector showing connected. Updating the trigger via POST /v1/code/triggers/{id} cleared ended_reason and restored enabled: true, suggesting the per-trigger repo authorization is a distinct grant from the user-level connector. Worth checking whether the manual-run failure is caused by the same per-trigger auth boundary.

RAW_BUFFERClick to expand / collapse

Summary

Manual Run now (both web UI and POST /v1/code/triggers/{id}/run) fails with HTTP 400 for any remote routine whose session_context.sources includes a git_repository. The same triggers run successfully on schedule. Triggers without a git_repository source run successfully on manual invocation.

Web UI symptom: clicking "Run now" returns a toast that reads Failed to start run. You can try again.

Reproduction

Two triggers in my account, identical except for the session_context.sources field:

Trigger A — succeeds on manual run

  • ID: trig_011QhQYx9rDHsCuYrzAyoYc1
  • session_context.sources: not set
  • POST /v1/code/triggers/trig_011QhQYx9rDHsCuYrzAyoYc1/run → HTTP 200

Trigger B — fails on manual run

  • ID: trig_01657vJF8Q5LSieeinAUerdK
  • session_context.sources: [{"git_repository":{"url":"https://github.com/taylor723/jack-tools"}}]
  • POST /v1/code/triggers/trig_01657vJF8Q5LSieeinAUerdK/run → HTTP 400
  • Body: {"type":"error","error":{"type":"invalid_request_error","message":"trigger_id: Extra inputs are not permitted"}}
  • Same response with empty body {} and with no body
  • Reproduces on a second repo-tied trigger, trig_01CjekgxtchffSng8jw727cc

Sample failed request_ids (today, 2026-05-04):

  • req_011CahqZuZ26zmqiKMDneKSY
  • req_011Cahq88bMpYsPJNtyBPhLr
  • req_011Cahqb8ySKDzEenPfUQLUe

Expected behavior

Manual Run now should kick off the routine for repo-tied triggers as it does for non-repo-tied ones. The trigger_id: Extra inputs are not permitted error message is also misleading — trigger_id is the path parameter, not a body field, so the validation message points users at the wrong thing.

Actual behavior

API rejects every manual run for repo-tied triggers with the same validation error. Scheduled fires for those same triggers complete normally (verified by past run history before triggers were updated). Result: there is no way to validate a repo-tied routine before its next scheduled fire.

Side note (possibly related)

A repo-tied trigger in my account auto-disabled itself with ended_reason: "auto_disabled_repo_access" shortly after creation, even with the user-level GitHub connector showing connected. Updating the trigger via POST /v1/code/triggers/{id} cleared ended_reason and restored enabled: true, suggesting the per-trigger repo authorization is a distinct grant from the user-level connector. Worth checking whether the manual-run failure is caused by the same per-trigger auth boundary.

Environment

  • Claude Code (Opus 4.7, 1M context) on Windows 11
  • Triggers created via the schedule skill (Claude Code) on 2026-05-03 and 2026-05-04
  • Claude.ai web UI shows GitHub connector as connected

extent analysis

TL;DR

The issue can be resolved by investigating and potentially adjusting the authorization settings for the GitHub repository connection in the Claude Code triggers.

Guidance

  • Verify the GitHub connector status in the Claude.ai web UI and ensure it is connected.
  • Check the trigger's session_context.sources field to confirm it includes the correct GitHub repository URL.
  • Investigate the per-trigger repo authorization settings, as the issue might be related to the distinct grant from the user-level connector.
  • Test manual runs with different triggers and repository connections to isolate the issue.

Example

No code snippet is provided as the issue seems to be related to configuration and authorization settings.

Notes

The issue might be specific to the Claude Code environment and the GitHub connector integration. Further investigation is needed to determine the root cause and apply the correct fix.

Recommendation

Apply workaround: Investigate and adjust the authorization settings for the GitHub repository connection in the Claude Code triggers, as the issue seems to be related to the per-trigger auth boundary.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Manual Run now should kick off the routine for repo-tied triggers as it does for non-repo-tied ones. The trigger_id: Extra inputs are not permitted error message is also misleading — trigger_id is the path parameter, not a body field, so the validation message points users at the wrong thing.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Remote routines: manual Run now fails (HTTP 400) for any trigger with a git_repository source [1 comments, 2 participants]