[BUG] Cowork scheduled task hangs when using Todoist MCP tools in a background session

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

A Claude Cowork scheduled task ("Gmail → Todoist Inbox Sweep") that reads Gmail and adds tasks to Todoist reliably works when run live/interactively in an attended chat session, but reliably hangs and does nothing when fired on its own schedule as an unattended background session. The background session gets stuck at ROUTINE_RUN_STATUS_PENDING and eventually times out to ROUTINE_RUN_STATUS_ABANDONED, with zero Todoist tasks created — even when the Gmail inbox verifiably contains actionable mail for that time window.

Environment

Product: Claude Cowork (desktop app), scheduled tasks feature (trigger/Routine)
Trigger ID: trig_01PTbgywW3bfdCveZKjfDer6, name "Gmail → Todoist Inbox Sweep (montclair.edu)"
Schedule: 0 13,16,19,22 * (UTC) — 4x/day
MCP servers involved: Gmail (built-in connector) and Todoist (community MCP server)
Model: claude-sonnet-5

Observed behavior

At least 3 separate fires reproduced the hang:

Scheduled 6pm run, Sept 1, 2026
Manual test fire via fire_trigger, session cse_01QEbbDpotthTwqWXwwfpMhp, fired 2026-09-03T12:36:30Z

Scheduled 6pm run, Sept 2, 2026
In each case: last_run.status stayed ROUTINE_RUN_STATUS_PENDING for 13+ hours, eventually flipping to ROUTINE_RUN_STATUS_ABANDONED.

Zero Todoist tasks were added by any of these runs, despite genuinely actionable email existing in the scan window (independently verified via a manual Gmail search covering the same window).

The same prompt, run live in an attended chat session (i.e., not via the scheduler), completes normally and adds the correct Todoist tasks within seconds.

What I tried

Suspecting that a fresh background session might not have the Todoist MCP server's tools connected/loaded yet (this session's own transcript showed Todoist tools initially listed as "deferred" and needing an explicit ToolSearch call to load), I updated the scheduled task's prompt to add an explicit "Step 0": check whether the Gmail/Todoist tools are available before calling them, call ToolSearch to load them if not, retry once on hang/error, and explicitly end the run (rather than silently no-op) if a connection problem persists.

This did not fix it — a subsequent test fire after the change was still stuck at PENDING with zero tasks added roughly 40 minutes after firing.

Expected behavior

An unattended/background Cowork scheduled-task session should either complete successfully or fail visibly (with an error status and/or a way for me to see what went wrong) — not hang indefinitely and silently produce no output while still showing as "in progress" for many hours.

Impact / workaround

Because the hang is silent and indistinguishable from "still running," it went unnoticed for several days (Aug 25 onward under the prior Google-Calendar-based version of this same task, then again under this Todoist version). Current workaround: the scheduled task has been disabled, and I'm running the same Gmail-scan-and-add-to-Todoist workflow manually in live chat sessions instead, which works reliably every time.

What Should Happen?

Claude should create Inbox items in Todoist after pulling action items from Gmail.

Error Messages/Logs

Steps to Reproduce

1. Set up a Cowork scheduled task whose prompt uses both the Gmail MCP tools (search_threads, get_thread) and the Todoist MCP tools (find-tasks, add-tasks).
2. Let the scheduled task fire on its own (unattended), OR use fire_trigger to fire it manually without an attached interactive session.
3. Observe the resulting session/run status via list_triggers / last_run.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

n/a

Claude Code Version

Claude 1.44121.4 (0d57a2) 2026-09-02T23:50:20.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_