[BUG] Routine-fired cloud sessions start with no repository — create_trigger cannot attach sources, and firings don't inherit the environment's repo
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?
Routines (scheduled triggers) created via the claude-code-remote MCP create_trigger with create_new_session_on_fire: true spawn sessions that have NO repository checkout, even though every interactive session in the same environment carries one. The stored session_request.config.sources is [] on every such trigger, and create_trigger has no parameter to set sources (unlike create_session, whose source_url works). The same firings also carry no MCP connectors (create_trigger warns "this trigger stores no MCP connectors … this call had none to pass through" even when called from a CCR session that works on the repo daily), so the github MCP tools are absent too. Net effect: a Routine-fired session in a repository environment can neither read the repo (no checkout, /home/user is empty) nor act on it via API (no github tools). Any scheduled task that touches a repository — watchdogs, maintenance, cron-recovery — is impossible by construction.
What Should Happen?
Either create_trigger accepts repository sources the way create_session does, or fresh-session firings inherit the repository configuration of the environment / creating session. A Routine fired in a repo-backed environment should wake up with that repo checked out, like every interactive session there does.
Error Messages/Logs
# every create_trigger(create_new_session_on_fire: true) response:
"session_request": { "config": { "sources": [], ... } }
# create_trigger warning:
warning: this trigger stores no MCP connectors, so the sessions it fires will run
without connector (mcp__<server>__*) tools. ... this call had none to pass through
(no session context, or no passable connector grants).
# control-probe session's own post-turn summary (fresh session, no source_url):
"status_detail": "diagnostic complete: no checkout found at /home/user/<repo>"
"recent_action": "no <repo> checkout in workspace; /home/user empty"
Steps to Reproduce
- In a cloud environment whose interactive sessions carry a GitHub repository (container CLI 2.1.283), call create_trigger with create_new_session_on_fire: true and a prompt that requires the repo (e.g. "run git log origin/main -1 in the repository and report"). Observe sources: [] in the response.
- fire_trigger it. The firing itself succeeds (last_run: SUCCEEDED) — our fired session cse_01VojBe3ST7cs4HHJJ1YDVvZ (2026-09-26T15:27:28Z) ran ~20 s with nothing to work on.
- Control A: create_session in the same environment with NO source_url and a prompt to look for the repo → session session_01R99GgfYzkFtYgt45NKwgpL reports /home/user empty (summary quoted above).
- Control B: create_session WITH source_url → session session_012QvdcWLqRZ6DWRGWW4jkx7 gets the checkout and verifies git fetch works. The capability exists; create_trigger just cannot express it.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
n/a
Claude Code Version
2.1.283 (cloud container)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Motivating case: GitHub Actions' cron silently dropped three consecutive scheduled runs for a repository on 25–26 Sept 2026; a Routine was the natural scheduler-independent backstop (check for the expected commit, push a marker-file kick if absent), and this defect closes that route entirely. The workaround is leaving the platform for the job (an external cron calling GitHub's workflow-dispatch API). Related but distinct open issues: #95450, #97266, #94748.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗