[Routines] Repo snapshot pins at routine save-time and never refreshes — request fresh-clone-per-fire (or opt-in)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code Routines (research preview) clone the configured GitHub repo once at routine create/save time and reuse that snapshot for every subsequent fire. Commits pushed to the configured branch after that point are not visible in the routine's working tree until the prompt is manually edited and re-saved at claude.ai/code/routines. This is undocumented, and it's a silent failure mode — the routine runs to completion against stale code, with no signal that newer commits exist.

Proposed Solution

Two options, in preference order:

1. Default to fresh git clone (or git pull) per fire. This matches the mental model of "configure repo: main, branch: main"

and what the docs imply.

1. Add an opt-in toggle: "Refresh repo on every fire (default off/on)". Off keeps current pinning for

reproducibility-sensitive users; on gives fresh-clone semantics.

If neither is feasible short-term:

1. Document the pinning behavior at https://code.claude.com/docs/en/routines.
2. Surface the snapshot SHA in the routine UI (and ideally in the /fire API response), plus a warning if the snapshot is N

commits behind the configured branch.

Alternative Solutions

See above

Priority

High - Significant impact on productivity

Feature Category

File operations

Use Case Example

Reproduction

1. Create a routine pointing at a GitHub repo (branch main).
2. Give it a thin-shell prompt: You are a Claude Code routine. Read \docs/routine-prompts/example.md` from the cloned repo

and follow it exactly.`

1. Push a commit to main that creates docs/routine-prompts/example.md.
2. Fire the routine.

Expected: routine reads example.md from the latest main.

Actual: routine reports "file doesn't exist" and either fails or silently falls back to whatever was in the snapshot from
step 1.

Live trace from a fire we ran while diagnosing this (session session_01NCUCfPpUmKRGBrVNSBbKC9, 2026-04-28 ~14:39 UTC). The
routine's own narration:

▎ "The file docs/routine-prompts/klaus-kb-research.md doesn't exist. The closest match is the kb-research skill. Let me read
▎ it and invoke it."
▎
▎ "The routine prompt file doesn't exist, but the equivalent kb-research skill does. Invoking it now."

The file in question had been on main for >17 hours at fire time (commit faa51ce in briangflett/klaus). The routine never saw
it. After dirtying and re-saving the prompt, the next fire saw the file fine. If Anthropic engineers can correlate that
session ID to server logs, the snapshot SHA the routine was running against vs. the latest main SHA should make the pinning
behavior explicit.

Workaround: open the routine, dirty the prompt field (add then remove a space), click Save. The next fire honors the latest
main. There is no other way to refresh the snapshot short of toggling Active off→on or recreating the routine entirely.

Impact

The thin-shell pattern recommended for keeping routine logic in version control silently breaks the moment a prompt and a
repo file evolve together. The prompt's expectation diverges from the snapshot's contents with no warning.

We hit this on a setup with five routines all using the thin-shell pattern, fired by an n8n scheduler workflow (cron
pre-checks → POST /fire). After a main push that touched files four of the routines depend on, they all silently ran stale
logic for >17 hours before a different downstream failure surfaced the staleness. The claude.ai routine UI shows none of:
snapshot age, snapshot commit SHA, or divergence from configured branch HEAD. The API /fire response also doesn't include any
snapshot identifier.

The manual workaround scales linearly with routine count — touching five routine configs by hand after every dependent push
is friction that defeats the "logic-in-git" pattern. We're running this against a Klaus-style personal-assistant stack where
push frequency is daily; that pattern probably generalizes to anyone using routines as cron-driven backends rather than
one-off scripts.

Additional Context

Environment

│ Routines │ research preview (claude.ai/code/routines) │
│ Plan │ Claude Max │
│ Setup scale │ 5 routines, all thin-shell, fired by n8n scheduler with cron pre-checks │
│ Repo │ GitHub, branch main │
│ Prompt pattern │ thin-shell (instructions reference a path inside the cloned repo) │
│ Triggers │ API (POST .../fire) and manual; behavior identical │
│ Diagnostic session │ session_01NCUCfPpUmKRGBrVNSBbKC9 (2026-04-28) │