Remote routines: manual Run now fails (HTTP 400) for any trigger with a git_repository source

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