[FEATURE] Trigger a local routine on demand via a local command / IPC (not only cron)

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

Today a local routine in the desktop app can only be started by its cron schedule (or manually in the UI). Cloud triggers already support on-demand runs via POST /v1/code/triggers/{id}/run, but those execute in a cloud environment against a git repo — they cannot touch the local filesystem or use locally-stored credentials.

That leaves a gap for event-driven local automation. My case: a macOS launchd job wakes a Python script the moment a file lands in a synced folder. The script does everything except the part that needs a model's judgement — and it has no way to hand that part over. Its only options are to wait for the next cron firing (hours) or to notify me and hope I'm at my desk.

Proposed Solution

A local command / IPC entry point, e.g.

claude routine run <routine-id> [--arg key=value]

that asks the running app to start an existing routine immediately, in the same authenticated local session the cron firing would have used.

Why this is a security improvement, not just a convenience: The only way to close this gap today is a long-lived headless credential on disk for a script to authenticate with. That is strictly worse. With a local trigger, the calling script holds no credential at all — it names a routine the user already created and approved, and the app decides whether to run it. Nothing new is granted; only the timing changes.

Rate limiting or a per-routine "externally triggerable" opt-in would be entirely reasonable. Even a debounced version (at most one external start per N minutes) would solve the whole class of problem.

Alternative Solutions

• Wait for the next cron firing — hours of latency; defeats the point of event-driven automation.
• Notify the user and have them start the routine manually in the UI — requires a human at the desk; not automation.
• claude -p (headless CLI) — not a substitute: it returns 401 while claude auth status reports loggedIn: true (and exits 0), so headless CLI auth is not a reliable path.
• Store a long-lived headless credential on disk for a script to authenticate with — the only currently-viable path, and strictly worse from a security standpoint (see above).

Priority

Medium — Would be very helpful

Feature Category

Automation / routines

Use Case Example

A launchd job fires a Python script the instant a file lands in a synced folder. The script preprocesses the file, then needs a model's judgement on one step. With claude routine run <routine-id> it can hand that step to an already-approved local routine immediately — holding no credential itself — instead of waiting hours for the next cron firing or paging a human.

Additional Context

Related to #72152 (sub-hourly local cron) — that request tightens the schedule; this one adds an on-demand / event-driven entry point so local automation doesn't depend on cron granularity at all. The two are complementary.