Routines: editing a trigger's repo/connectors/prompt fails to save, but the enabled toggle persists independently (can silently re-arm a misconfigured routine)

Context: Created a routine trigger via the POST /v1/code/triggers API (RemoteTrigger tool in Claude Code), setting only name and cron_expression — intentionally left enabled: false since the API has no documented way to attach a repository, prompt, or model (see below). Handed off to the web UI at claude.ai/code/routines to finish configuration, as the routines docs recommend.

What happened in the web UI (claude.ai/code/routines):

1. Opened the trigger for editing.
2. Successfully connected a GitHub repository.
3. Successfully removed the two connectors that were included by default (Google Calendar, Google Drive — unrelated to the routine's purpose).
4. Pasted the routine's prompt/instructions and set the model.
5. Clicked Save → got a "failed to save" error. No further detail was visible to the user.

Observed via the API after the failed save (GET /v1/code/triggers/{id}):

• The connector removal did not persist — mcp_connections still listed both Google_Calendar and Google_Drive.
• The prompt/repository attachment also did not appear to persist (no fields for these are exposed in the API response, but the routine had no way to run coherently).
• However, enabled had flipped from false to true, and updated_at had advanced — meaning some part of the edit (the enable toggle) saved successfully and independently of the rest of the form, even though the "failed to save" error implied nothing was saved.

Impact: Because the enable toggle apparently commits separately from the bulk form save, a user can end up with a routine that is enabled and scheduled (this one had next_run_at ~3 hours out) while the fields that make it do anything useful (repo, prompt, connectors) silently failed to save. That's a worse failure mode than a simple error toast — it can arm a nightly/scheduled run with no prompt and no repository attached, with no warning that this is the state it's in. Had I not re-checked the trigger via the API, this would have fired unattended.

Repro-relevant detail that may be a contributing factor: this specific trigger was originally created via direct calls to the (apparently internal/undocumented) POST /v1/code/triggers endpoint rather than through the web UI's own creation flow. During that process, several guessed fields were silently accepted with no visible effect (e.g. a top-level repositories array returned 200 but never appeared in subsequent GET responses), while others were rejected outright as unknown protobuf fields (repository, repositories nested under job_config.ccr). It's possible the resulting trigger object was left in a shape the web UI's edit-and-save flow doesn't fully expect, which could explain why the bulk save specifically failed for this trigger. I don't have a control trigger created entirely through the UI to compare against.

Ask:

• Please check whether "failed to save" on the routine edit form can leave the record in a partially-saved state (enabled flips independently of the rest of the form).
• If there's a known reason hand-crafted-via-API trigger objects can end up in a UI-incompatible state, it'd help to have that documented, or have the UI validate/reject cleanly rather than silently partial-saving.

(No session ID/timestamp captured for this occurrence — happy to provide the trigger ID for the specific object involved if useful, will share out-of-band rather than post an account identifier here.)