Routines: allow naming a run when firing the API trigger

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

Feature request for Claude Code on the web (claude.ai/code) Routines.

Problem

I have a Routine with an API trigger. My app fires it once per event (a new
feedback item submitted in an internal tool), passing the event id in the
text payload. Each firing creates a fresh cloud session.

The Routine's "Runs" list labels every run only with a timestamp and the
trigger type ("API"). With one run per event, the list becomes dozens of
identical rows — there is no way to tell which run handled which event without
opening each session.

Request

An optional name (or title) field on the per-routine /fire endpoint,
alongside the existing text field:

POST /v1/claude_code/routines/trig_xxx/fire
{ "text": "feedback_id=31 feedback_type=suggestion", "name": "Feedback #31" }

Shown as the run's label in the Runs list, and ideally used as the created
session's title.

text is documented as the only body field today, and unknown body fields are
ignored — so adding name is backward-compatible for existing callers.

Acceptable alternative: the /fire response already returns
claude_code_session_id and claude_code_session_url. A documented endpoint
to set a session's title would let the caller do a second call and get the same
result, if a rename API is easier to land than a new field on /fire. (A
name on /fire is still preferable — one call, and it labels the run row and
not just the session.)

Workarounds today, and why they fall short

• Sessions can be renamed manually after the fact (dropdown next to the

session title) — but that is per-run manual work, and the Runs list on the
Routine page still shows only timestamps.

• Session auto-titles summarize the first prompt, but every run of a Routine

starts with the same stored prompt, so all runs title alike. Instructing the
agent to open its first reply with an identifying line steers the auto-title
at best — and it is more indirect than it looks: fire text arrives wrapped
in a <routine-fire-payload> block labeled untrusted, so the saved prompt has
to explicitly opt in to reading the payload before the agent can echo anything
from it.

Why it matters

Event-driven Routines (one fire per ticket / alert / webhook) are a natural
fit for the API trigger, and they all hit this: the caller knows exactly what
the run is about at fire time, but has nowhere to put that knowledge. The docs'
own examples — alert triage keyed to an alert ID, deploy verification per
deploy — are all one-fire-per-event, and none of them can label the run with
the ID they just passed in. GitHub-triggered routines have the same shape (each
matching event starts its own session), so a per-run label would help there too.

Environment

• Claude Code on the web (claude.ai/code), Routines research preview
• /fire under beta header experimental-cc-routine-2026-04-01

Proposed Solution

Request

An optional name (or title) field on the per-routine /fire endpoint,
alongside the existing text field:

POST /v1/claude_code/routines/trig_xxx/fire
{ "text": "feedback_id=31 feedback_type=suggestion", "name": "Feedback #31" }

Shown as the run's label in the Runs list, and ideally used as the created
session's title.

text is documented as the only body field today, and unknown body fields are
ignored — so adding name is backward-compatible for existing callers.

Acceptable alternative: the /fire response already returns
claude_code_session_id and claude_code_session_url. A documented endpoint
to set a session's title would let the caller do a second call and get the same
result, if a rename API is easier to land than a new field on /fire. (A
name on /fire is still preferable — one call, and it labels the run row and
not just the session.)

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_