[BUG] Desktop scheduled tasks evaluate cron in UTC-5 while system timezone is America/Los_Angeles — all tasks fire 2h early, re-arming doesn't fix

What's wrong

On macOS, the desktop app's scheduled tasks are evaluating cronExpression in a fixed UTC-5 offset, while the system timezone is America/Los_Angeles (PDT, UTC-7). Every recurring task fires 2 hours early, and the scheduler's own nextRunAt / lastScheduledFor are computed in that same UTC-5 zone, so nothing in the UI looks wrong — the human-readable schedule string still says "At 08:00 AM".

The tool docs say cronExpression is "LOCAL time (not UTC)".

Environment

• Claude desktop app 2.16120.0 (Code tab), Claude Code 2.1.195 CLI / 2.1.284 bundled
• macOS 26.6.2, "Set time zone automatically" on
• date → Wed Oct 7 10:39:38 PDT 2026; /etc/localtime → America/Los_Angeles
• No TZ env var on the app process
• Main app process has been running since 2026-09-30 09:35 PDT (not restarted since)

Evidence

Task A, cron 0 8,12 * * 1-5, jitterSeconds 12:

| run | started_at (UTC) | PDT | expected PDT |
|---|---|---|---|
| 2026-09-29 | 15:01Z | 08:01 | 08:00 ✅ |
| 2026-09-30 (before the current app process started) | 14:59Z / 15:05Z | ~08:00 | 08:00 ✅ |
| 2026-10-05 | 17:01Z | 10:01 | 12:00 ❌ |
| 2026-10-07 | 13:00Z | 06:00 | 08:00 ❌ |
| 2026-10-07 | 17:00Z | 10:00 | 12:00 ❌ |

Every run since the current app process launched is offset by exactly 2h (= UTC-5 instead of UTC-7).

From scheduled-tasks.json, Task B, cron 45 7 * * 1-5:

"lastScheduledFor": "2026-10-07T12:45:00.000Z"   // = 07:45 at UTC-5, = 05:45 PDT

list_scheduled_tasks shows the same offset in nextRunAt for every enabled task:

• cron 45 7 * * 1-5, jitter 563s → nextRunAt 12:54Z (should be 14:54Z)
• cron 0 14 * * 0, jitter 294s → nextRunAt 19:04Z (should be 21:04Z)

Re-arming does not fix it. I edited both crons via update_scheduled_task today (2026-10-07); the freshly computed nextRunAt is still UTC-5 (cron 45 9 → 14:54Z, cron 0 10,14 → 19:00Z).

Relation to existing issues

• #88638 (cron evaluated in the timezone a task was armed in) is the closest. Differences here: nextRunAt itself is wrong (not just dispatch vs. nextRunAt), and re-arming/editing the task does not fix it — newly computed slots are still UTC-5. That suggests the long-running app process is holding a stale/incorrect zone (e.g. a cached ICU/V8 timezone from launch), not a per-task binding. I have not knowingly changed the system timezone, but automatic timezone is on, so a transient change around app launch can't be ruled out.
• #90485 (tasks dispatch ahead of fire time) may share a cause.

I have not yet restarted the app to see whether that clears it — leaving it running in case diagnostics are useful.

Impact

Any task tied to a real-world clock runs at the wrong time, silently. One of mine is meant to run after the US stock market opens; it ran before the open, read an empty order book, and wrote pre-market data into a daily record. Nothing in the app indicated the schedule had shifted.

Expected

Evaluate cron against the system's current timezone at evaluation time, so nextRunAt / dispatch match the documented "local time". Showing nextRunAt in local time in the task list would also make this kind of drift visible.

Workaround

Shifted each cron +2h. This will make every task 2h late once fixed.