[BUG] Scheduled tasks report success but silently perform zero work

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?

Scheduled tasks ("Routines" / create_trigger in the Cowork/Claude Code Remote MCP) fire on schedule — last_fired_at advances correctly every time — but produce zero actual work. No tool calls are executed, no output is produced, and no error is surfaced anywhere. This has been continuous for more than 30 hours across dozens of firings, on both a Pro-plan Cowork account and its bound scheduled tasks.

I also opened a support ticket about this through the in-app "Get help" flow (Fin) more than 24 hours ago. Fin acknowledged the issue and said it would pass it to the Product Support team, but no human has responded since — only repeated automated "Thanks for following up!" replies with no new information.

Environment

• Product: Cowork (Claude app), scheduled tasks created via the claude-code-remote MCP server (create_trigger / list_triggers tools)
• Plan: Claude Pro
• Timeframe of the bug: continuously from at least 2026-08-24 through 2026-08-25 (still ongoing as of this report)

Steps to reproduce

1. Create a scheduled task via create_trigger with a cron schedule and a detailed prompt instructing an agent to read email via a connected Microsoft 365 MCP, query a connected JobTread (Pave API) MCP, and take several write actions (create/update records, send an email, apply email categories).
2. Let the schedule fire repeatedly (in my case: an hourly task on 0 12-22 * * 1-5, and a separate daily digest task on 0 11 * * 1-5).
3. Provide clear input for the task to act on (in my case, test emails with an exact matching subject line sitting unread in the target inbox, plus a corresponding record deliberately absent from the target CRM so the run has unambiguous work to do).
4. Observe via list_triggers that last_fired_at advances on schedule as expected.
5. Observe that none of the expected side effects occurred: no email category was applied, no CRM record was created or updated, no digest email was sent, and no comment, task, or log entry was created anywhere.

Expected behavior

Each firing should actually execute the configured prompt in a fresh session and perform the described tool calls, or, failing that, surface a visible failure/error state (e.g., last_run status other than "succeeded", or a bounce/error notification).

Actual behavior

• last_fired_at (and next_run_at) advance normally every single firing, which reads as "healthy" from list_triggers — there is no visible signal that anything is wrong.
• No downstream effect from any firing has occurred: dozens of hourly firings and multiple daily-digest firings (including one manually fired on-demand via fire_trigger, which also returned a normal-looking session_id with no error) have produced nothing.
• I manually re-ran the identical prompt in an interactive (non-scheduled) session in the same account, and it worked correctly on the first try — read the target email, matched/created the CRM record, wrote the expected fields, and sent the expected email. This isolates the failure to the scheduled/background execution path specifically, not the prompt, the MCP connections, or account permissions.
• Two independent test emails sent at different times (2026-08-25T17:49:10Z and 2026-08-25T18:55:04Z) remain completely unprocessed by an hourly task that has fired at least 8 times since either email arrived.

Why this doesn't look like the cited service incident

Anthropic's support bot (Fin) initially attributed this to a posted status-page incident ("Elevated Errors for Multiple Models," 2026-08-24 ~04:50–07:36 UTC, resolved 08:30 UTC, affecting Opus 5 / Fable 5 / Mythos 5 / Opus 4.8). Two things don't line up:

• Timing: failures have continued for 30+ hours past that incident's resolution time (confirmed as recently as 2026-08-25T21:00Z+).
• Failure mode: the cited incident describes elevated errors; what I'm seeing is not errors — it's silent no-ops with a "successful" firing status. A degraded-model incident wouldn't typically produce a clean success status with zero effect.

Impact

This is a business-critical automation (a voice-note-to-CRM pipeline for a small contracting business) that has been completely non-functional for over a day, silently, with no error surfaced anywhere a user would see it — the only way I detected it was by manually verifying downstream state after the fact.

Support ticket status

Opened via in-app "Get help" (Fin) approximately 2026-08-24. As of this report (2026-08-25, 24+ hours later), only automated Fin responses have been received; no human from the Product Support team has replied.

What Should Happen?

Each firing should actually execute the configured prompt in a fresh session and perform the described tool calls. Failing that, it should surface a visible failure state — e.g. a last_run status other than "succeeded", or an error/bounce notification — rather than reporting success while doing nothing.

Error Messages/Logs

`That's the core of the bug: there are no error messages or logs anywhere. list_triggers reports last_fired_at and next_run_at advancing normally on every firing, and a manual on-demand fire (via fire_trigger) returned a normal-looking session_id with no error — nothing anywhere indicates failure. The only way I detected the problem was by manually checking whether the expected downstream actions (email categorized, CRM record created/updated, digest email sent) actually happened, and finding they hadn't.
Example trigger IDs showing this pattern:
trig_01QTYf3M8TBwaKxgMcjzEvBw ("CRM Voice Log Filing," hourly) — last_fired_at advanced on schedule across dozens of firings between 2026-08-24 and 2026-08-25, zero downstream effect each time.
trig_01ECPLNFxjUx2siMwSZXGN89 ("Daily Call List Digest") — fired both on its cron schedule (2026-08-25T11:09:22Z) and via a manual fire_trigger call (2026-08-25T14:26:13Z), neither produced the expected digest email.`

Steps to Reproduce

1. Create a scheduled task via create_trigger with a cron schedule and a prompt instructing an agent to read email via a connected Microsoft 365 MCP, query a connected JobTread (Pave API) MCP, and take write actions (create/update records, send email, apply email categories). 2. Let the schedule fire repeatedly (I used an hourly task on "0 12-22 1-5" and a daily task on "0 11 1-5"). 3. Provide clear input for the task to act on — e.g. a test email with a matching subject sitting unread in the target inbox, and a corresponding record deliberately absent from the target CRM. 4. Check list_triggers — last_fired_at/next_run_at advance normally, looking healthy. 5. Check whether the expected side effects actually happened (email category applied, CRM record created, digest sent) — they don't, with no error anywhere. 6. For comparison: running the identical prompt manually in an interactive (non-scheduled) session in the same account works correctly on the first try, which isolates the failure to the scheduled/background execution path specifically.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — this bug is in Cowork's scheduled tasks feature (Claude app), not the Claude Code CLI. Reported here because this is where Anthropic engineers monitor platform bugs.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_