[BUG] Cowork scheduled tasks silently dropping fires — June 2026 recurrence (references #55378)

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?

Note: This bug is about Cowork mode in the Claude desktop app (the scheduled-task system, mcp__scheduled-tasks__*), not the Claude Code CLI. Filing here because that's where Cowork bugs are tracked. Several template fields below (Claude Code Version, Terminal/Shell) are not applicable.

Summary

The same Cowork scheduled-task silent-drop regression reported in #55378 (closed as not planned, marked stale) is recurring on my account in June 2026. A recurring weekday cron task (distill-context-reminder, 0 18 1-5, weekdays 6:10 PM local) ran reliably for ~6 weeks, then silently skipped three consecutive scheduled fires on 2026-06-09 (Tue), 2026-06-10 (Wed), and 2026-06-11 (Thu). The Friday 2026-06-12 fire did execute (~5 minutes late, within jitter window). No error was surfaced; enabled: true; the task appears healthy in the sidebar and in list_scheduled_tasks output.

The bug is recurring, not a one-time event. The original reporter on #55378 observed weekend drops in mid-April that bled into weeknights. My pattern is weeknight drops six weeks later. Closing #55378 as "not planned" appears premature — the underlying defect is still shipping.

Why this matters

The dropped task is a low-stakes reminder in my case, so I caught it manually. But I have other scheduled tasks on the same scheduler that ARE load-bearing — Day-30/60/90 strategic reviews and a Day-42/63/84 prompt-battery rerun cadence tied to a 90-day measurement window. A silent drop on one of those would corrupt the measurement series with no way to detect it after the fact. The reliability of the scheduler is the load-bearing property; silent failure is the worst-possible failure mode.

The original reporter's two-channel detection problem applies here too: I cannot use Cowork scheduled tasks as their own monitoring channel, because they are the failure mode.

What Should Happen?

Per #55378: scheduled tasks should fire at their configured times. Recurring cron tasks' lastRunAt should advance through each fire window. If a fire cannot occur for any reason, the user should be notified through a channel that does not depend on the same scheduler.

Error Messages/Logs

No errors or logs surfaced — silent drops, consistent with #55378.

Evidence from mcp__scheduled-tasks__list_scheduled_tasks after the affected window:

Task: distill-context-reminder
Cron: 0 18 * * 1-5 (Mon–Fri 6:10 PM local; jitter ~10 min)
Enabled: true
Last successful run before drop: 2026-06-08 (Mon) ~6:10 PM local
   (verified via session transcript and journal pass marker)
Skipped fires:
   - 2026-06-09 (Tue) — no session created, no transcript
   - 2026-06-10 (Wed) — no session created, no transcript
   - 2026-06-11 (Thu) — no session created, no transcript
Next successful run: 2026-06-12 (Fri) at 6:15 PM local
   lastRunAt: 2026-06-13T01:15:16.818Z (UTC)
   nextRunAt: 2026-06-16T01:09:36.000Z (UTC) (Mon 6/15 6:09 PM local — correct)

Verified via mcp__session_info__list_sessions: zero "Distill context reminder" sessions exist between the 2026-06-08 run and the 2026-06-12 run. The skipped fires produced no session at all — not a session that errored, but no session.

Environmental conditions during the skipped windows (confirmed by me):


Claude desktop app was running.
Computer was awake (not asleep, lid not closed).
I was actively using Cowork during at least one of the skipped windows.
Task remained enabled and visible in the sidebar throughout.
No connector auth issues.
No app crashes or restarts.

Steps to Reproduce

Same pattern as #55378 — not deterministic; observed across multiple consecutive fire windows.

In Cowork mode, configure a recurring weekday cron task (e.g., 0 18 1-5).
Verify it runs successfully for multiple weeks.
Observe lastRunAt and session history via mcp__session_info__list_sessions after each expected fire window.
Specific fires are silently skipped: no session is created, no error is logged, lastRunAt does not advance through the missed window, nextRunAt jumps forward to the following window. Task remains enabled: true and reports as healthy.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Task ran successfully on 2026-06-08 (Mon) and on multiple prior weekdays in May 2026 and early June 2026.

Claude Code Version

N/A — this bug is about Cowork mode in the Claude desktop app, not Claude Code CLI.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

This is a recurrence of the silent-drop pattern documented in #55378. Closing that issue as "not planned" while the underlying defect continues to ship is concerning. Requesting:

Reopening #55378 or treating this as a continuation.
Confirmation the silent-drop behavior is being investigated at the platform / scheduler-service level.
Visibility into whether this affects other accounts in the June timeframe.
An out-of-band notification path so silent drops become detectable.
Any reliable user-side workaround beyond moving critical tasks off the Cowork scheduler entirely.