[FEATURE] Routine API trigger: send a follow-up into a session the routine started

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

A self-hosted service starts Claude Code cloud sessions for its users and later sends them follow-ups, with nobody at a keyboard.

That takes claude -p "msg" --cloud <session-id> on a host signed in with claude auth login. Per Authenticate from CI, the refresh grant is capped at 30 days and "There is no long-lived CI token for this today." So someone signs in again every month, and the host holds the account's whole user:sessions:claude_code scope to reach a few sessions.

Routine API triggers almost fit: the token is "scoped to triggering that routine only". But each /fire call starts a new session, and the body takes only text, so the token can't reach a session it already started.

Binding a routine to one session (persistent_session_id) doesn't cover this. The binding is part of the routine, so a service that starts sessions on demand would need a routine per session. And fire_trigger on a bound routine starts a new session today anyway (#94748).

Proposed Solution

Accept an optional session_id in the fire body:

POST /v1/claude_code/routines/trig_.../fire
{"session_id": "session_...", "text": "CI passed. Merge the PR."}

With session_id, the endpoint queues the text into that session instead of starting a run, as claude -p --cloud <id> does. The text stays wrapped in <routine-fire-payload> like fire text today, and the endpoint rejects sessions this routine didn't create, so the token stays narrow and revocable.

Alternative Solutions

• Workaround: a host running claude -p --cloud <id>, with claude auth login redone every 30 days.
• A revocable token that can only post messages to one session, which would also cover sessions no routine started.
• Related: #92127 (unattended Remote Control credential, same 30-day cap).

Priority

Medium - Would be very helpful

Feature Category

API and model interactions

Use Case Example

1. The service fires the user's routine to fix a failing test and gets a session id back.
2. The session pushes a branch and asks whether to regenerate the snapshots too.
3. A teammate answers an hour later, and the service sends the reply into that session with the routine token.

Additional Context

Checked against the docs and changelog at 2.1.294 (October 8, 2026). I can share more detail on the setup if useful.