[BUG] Scheduled tasks have no timezone option — recurring local times drift at DST (cron is UTC-only; CRON_TZ works but is undocumented)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Scheduled tasks (the Cowork / Claude Code Remote trigger tools create_trigger / update_trigger) accept only a 5-field cron expression documented as evaluated in UTC, with no timezone or wall-clock field. So a recurring task set for a local time (e.g. a 9:30 PM reminder) is stored at a UTC offset frozen at creation time, and drifts by an hour at every DST transition. There is no documented way to pin a fixed local time that survives DST — a user-visible wart for the most basic "remind me at 9:30pm" use case.

Additional finding (important)

The underlying scheduler actually does honor a CRON_TZ=<IANA zone> prefix, but this is undocumented and directly contradicted by the tool's own description ("evaluated in UTC … convert local times to UTC first").

Verified empirically: setting CRON_TZ=America/Los_Angeles 30 21 * * * scheduled the next run at ~04:30 UTC (= 9:30 PM Pacific), not 21:30 UTC — i.e. the zone was applied. So the capability exists but is hidden and unsupported: integrators either don't know it's there or can't safely rely on it (per the docs it should be ignored).

Impact

Any recurring task tied to a person's daily rhythm (a morning brief, an evening wind-down, a "before bed" reminder) silently shifts by an hour twice a year unless someone remembers to hand-edit the cron. Confusing and easy to miss.

Reproduction

1. Create a scheduled task for a local time using the documented UTC cron — e.g. 9:30 PM PT → 30 4 * * *. Correct only until the next DST change, after which it fires at 8:30 PM.
2. Alternatively set CRON_TZ=America/Los_Angeles 30 21 * * * → it is accepted and next_run_at is computed in Pacific (it works) — which contradicts the documented UTC-only behavior.

Environment

Cowork (Claude app) · scheduled tasks via the Claude Code Remote trigger tools (create_trigger / update_trigger) · September 2026.

What Should Happen?

A first-class way to schedule a local wall-clock time that stays fixed across DST. Any one of, in order of preference:

1. An explicit timezone parameter (IANA name, e.g. America/Los_Angeles) on create/update trigger — store wall-clock time + zone and resolve per occurrence so DST is handled automatically.
2. Officially document and support CRON_TZ= in the cron expression.
3. At minimum, correct the tool description, which currently states UTC-only while the scheduler already honors CRON_TZ=.

Error Messages/Logs

Steps to Reproduce

1. Create a recurring scheduled task for a local time using the documented UTC cron. For "9:30 PM Pacific" you must enter 30 4 * * * (21:30 PT + 7h). It fires correctly at 9:30 PM — but only while PDT is in effect.
2. Wait for (or simulate) the next DST change. After the switch to PST the same task now fires at 8:30 PM Pacific — an hour early — with no warning. There is no way to express "9:30 PM local, always" through the documented interface.
3. Separately, set the cron to CRON_TZ=America/Los_Angeles 30 21 * * *. It is accepted and next_run_at comes back as ~04:30 UTC (= 9:30 PM PT), proving the scheduler honors the zone — even though the tool description states cron is evaluated in UTC only. So a fix largely exists already; it is just undocumented, unsupported, and contradicted by the docs.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.206 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_