[FEATURE] Cowork scheduled tasks: support multiple run times per day (Custom frequency)

### Preflight Checklist

- [X] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
- [X] This is a single feature request (not multiple features)

### Problem Statement

**Environment:** Claude Desktop 1.40609.0 (macOS), Cowork scheduled tasks.

The **Edit scheduled task** dialog offers `Frequency: Daily | Weekdays` plus a single time field. That is one fire per day, per task. There is no way to express "run this on weekdays at 7:45am, 12:15pm, and 5:30pm."

I run a recurring task that needs three passes a day at hours I choose — the source it reads is bursty, so the specific timing is the whole point. Neither available frequency can express that.

Both workarounds are bad:

**1. Create three near-duplicate tasks.** Each holds its own copy of a ~40-line prompt. They drift immediately — I edit one and forget the other two — and nothing in the UI indicates they are one logical schedule rather than three unrelated tasks.

**2. Bypass the dialog** and call `create_trigger` directly, which accepts a full 5-field cron expression. This works (`45 11 * * 1-5`, `15 16 * * 1-5`, `30 21 * * 1-5`), but I have to hand-convert local time to UTC myself, and the result is a schedule I now maintain outside the surface that is supposed to manage it.

Point 2 is the important one: **the scheduling engine already accepts arbitrary cron.** The dialog simply cannot express what the backend already supports. This reads as a presentation-layer gap rather than a platform limitation, which is why I am filing it as a small ask rather than a large one.

### Proposed Solution

**The ask: let Claude configure the schedule conversationally, so the dialog is not the only path.**

Claude already renders interactive multiple-choice cards mid-task to collect input. That is a UI the model composes at runtime with full context — and it can do something a static form structurally cannot: validate the schedule against what the task actually does.

A concrete example from setting this up. The script my task invokes enforces a 4-hour minimum gap between runs and fails closed. Claude checked my three proposed times against that constraint before creating anything, and confirmed the gaps (4.50h and 5.25h) cleared it. Had I picked times 20 minutes tighter, the third run would have fired, hit the gate, no-opped, and reported success — a task that "runs" on schedule and silently does nothing.

**A dropdown cannot catch that, because it does not know what the task invokes.** That asymmetry is the actual argument here. A static form has to offer options that are safe for everyone, so it cannot validate against my constraints; an agent that already knows what the task runs can. Generalized: **treat agent-rendered controls as a first-class surface for configuring scheduled tasks** — "run this 3x on weekdays at 8, noon, and 5" creates them, validated against the task's real behavior.

**Fallback, if that is too large a change:** add a `Custom` option to the Frequency dropdown — pick the days, then add N times. One task, N fires, one prompt authored once. That solves my immediate problem, and only my immediate problem.

So, in order of preference:

1. Agent-rendered configuration for scheduled tasks, validated against what the task actually invokes.
2. Failing that, a `Custom` frequency in the dialog.

Either way, tasks created that way should stay visible and editable in the existing UI — this should widen the configuration path, not fork it.

**Related:** #50529 (optional IANA timezone field on scheduled triggers). Not a duplicate, and I do not want to split that discussion: #50529 is about *when* a stored schedule resolves to, this is about *how many times* it can fire. They compound, though — a multi-time schedule makes UTC/DST drift worse, because every slot drifts together. My three slots all need a +1 UTC hour correction on 2026-11-01. Both are needed for a multi-slot schedule to survive a DST boundary.

### Alternative Solutions

Three I have actually tried:

1. **Three separate tasks, one per time slot.** Works today and needs no changes from you. The cost is prompt duplication — three copies of the same ~40-line instruction that must be edited in lockstep — and no indication in the UI that they belong together.

2. **Call `create_trigger` directly with cron.** What I ended up doing. `45 11 * * 1-5` / `15 16 * * 1-5` / `30 21 * * 1-5` for 7:45am / 12:15pm / 5:30pm ET. Correct, but I had to do the local-to-UTC conversion by hand, and I had to write a small script to keep the local-time intent recorded somewhere, because cron alone does not retain it.

3. **Leave the product's scheduler entirely** — `launchd` on my Mac firing `claude -p` headless on whatever cadence I want. Total control, and I already run another pipeline this way. But it means the automation is no longer visible or manageable anywhere in Claude, which defeats the purpose of having scheduled tasks in the product.

The existence of option 2 is the argument for this request: the capability is already there, one layer down.

### Priority

Medium - Would be very helpful

### Feature Category

Configuration and settings

### Use Case Example

Scenario: a weekday task that scans a feed and takes one action per run.

1. Feed activity is bursty — morning, midday, and end of day. One run a day misses two of the three windows, so I want three runs at 7:45am, 12:15pm, and 5:30pm ET.
2. I open **Edit scheduled task**. Frequency offers `Daily` or `Weekdays`, and one time field. There is no way to enter three times.
3. I duplicate the task twice and set a different time on each. Now one prompt exists in three places. Two weeks later I improve the instruction, update one copy, and the other two silently run the old version.
4. I give up on the dialog and call `create_trigger` three times with cron expressions, converting ET to UTC by hand.
5. What I wanted instead: pick `Custom`, choose Weekdays, add three times, and have one task with one prompt fire three times.

Or, the version that would have been better still: tell Claude "run this on weekdays at 7:45, 12:15, and 5:30" and have it create the tasks — checking, as it did, that those times satisfy the 4-hour minimum gap the underlying script enforces before anything is created.

### Additional Context

**Environment:** Claude Desktop 1.40609.0, macOS, Cowork scheduled tasks (both the in-app dialog and the `create_trigger` MCP).

**Scope note:** this is about the scheduled-task dialog in Cowork/Claude Desktop rather than the CLI. I picked the closest available Feature Category; there does not appear to be one for scheduled tasks or Cowork specifically, which may itself be worth adding given how many issues in this repo are already labeled `area:routines`.

**On the two dropdown fields:** priority is genuinely medium for me — I have a working path via `create_trigger`, so nothing is blocked. I am filing it because the gap between what the dialog exposes and what the backend accepts looks small and cheap to close, not because I am stuck.

**Related:** #50529.

Start with the Cowork Edit scheduled task flow and the create_trigger entry point described in the issue. Compare the dialog's single-time model with the cron schedules the backend already accepts, then define how multiple times, weekday selection, validation, and timezone handling remain visible and editable in one task.

Escrito por el modelo de indexación a partir del texto del issue.