[FEATURE] Routines API: expose GitHub/API triggers and delete, so a routine can be managed without the web UI

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

The routines API (/v1/code/triggers, what /schedule drives) can create and update routines, but it cannot express everything the web UI can. Two gaps force a human back to the browser mid-workflow:

1. It can only create schedule triggers. The create body takes exactly one of cron_expression or run_once_at. GitHub-event and API (/fire) triggers are web-UI-only — the docs say as much: "/schedule in the CLI creates scheduled routines only. To add an API or GitHub trigger, edit the routine on the web."

So the natural shape of an event-driven routine — "review every PR when it opens" — cannot be provisioned programmatically. Ours had to be created with a placeholder weekday cron and then hand-edited in the UI to add pull_request.opened.

2. There is no delete. The API exposes list, get, create, update, run. Removing a routine is a UI click. enabled: false gets you an inert routine, but it stays in the list forever.

The practical effect is that routines can't be treated as managed configuration. We couldn't script setup, couldn't tear it down when we decided against it, and couldn't have checked either into version control.

Proposed Solution

Bring the API to parity with the trigger editor:

• Accept GitHub-event and API triggers in create/update — the event type plus the same filter fields the UI offers (author, title, body, base/head branch, labels, draft, merged), and for API triggers a token mint/rotate/revoke operation.
• Add DELETE /v1/code/triggers/{trigger_id}.

Ideally a routine becomes a declarative object you can apply from a repo, the way agents and environments already can be via ant beta:agents create < agent.yaml.

Alternative Solutions

• Create with a placeholder cron, then finish in the UI — what we did. Works once; doesn't survive as repeatable setup, and leaves a cron firing that you may not want.
• enabled: false instead of delete — leaves permanent clutter in the routines list.

Priority

Medium

Feature Category

API / SDK

Use Case Example

We evaluated routines as a replacement for a self-hosted agentic dev pipeline (k3d + a kubebuilder operator polling GitHub) for reviewing PRs on a private repo. Routines covered nearly all of it with no infrastructure, which was the appealing part.

But standing it up was: create via API → open the browser to add the real trigger → later, open the browser again to delete it. For something whose selling point is replacing infrastructure-as-code with managed config, the config itself isn't manageable.

We ultimately rolled the whole thing back for unrelated reasons, but the API gap was a real cost during the trial and would have been an ongoing one.

Additional Context

Related and previously closed:

• #58045 — enabledPlugins in Remote Triggers, closed as duplicate. Same theme: session_context not expressing what a session needs.
• #65724 — routine session visibility, closed as inactive.

Two smaller things noticed alongside, mentioned only because they're adjacent and I don't want to split them into noise:

• The routines documentation is stale on supported GitHub events. code.claude.com/docs/en/routines lists pull request and release only; the live trigger UI offers Issue opened as a first-class preset. Anyone reading the docs will conclude issue-driven routines are impossible.
• A session transcript at claude.ai/code/session_… returns 403 to non-browser clients, so there's no programmatic way to read what a run actually did. A routine that silently no-ops is indistinguishable from one that worked until a human opens the page. Some machine-readable run outcome would make routines self-verifying.