[BUG] Cloud-run Cowork scheduled task fires on time, then stalls mid-run at the first turn boundary

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 cloud-run Cowork scheduled task fires on schedule and completes successfully, but spends the overwhelming majority of its wall-clock time idle at a single point early in the run — after the deferred tool schemas load and before the first connector call. The work itself takes under four minutes; the run took 2h 25m.

This is not a "task didn't fire" bug. The platform recorded the task firing within 4 seconds of its cron time on both observed runs, and both runs finished with status SUCCEEDED. The defect is that the session is not driven forward once it has started.

Impact

The task is a 04:00 UTC weekday morning brief whose entire value is landing before the workday starts. A run that completes at 06:29 UTC delivers it mid-morning, after the recipient has already found the same information manually. The output is correct; it is simply too late to be worth anything.

Environment

| Field | Value |
|---|---|
| Product | Claude Cowork, cloud-run scheduled task (no device binding) |
| Task name | Morning brief |
| Trigger ID | REDACTED |
| Schedule | 0 4 * * 1-5 (UTC) |
| persist_session | false (each firing is a fresh cloud session) |
| Device binding | None. folders_state: FOLDERS_STATE_NONE, no folders |
| Model | claude-opus-5 |
| Created / last updated | 2026-09-04 / 2026-09-07, created_via: meta_mcp |
| Connectors attached | Microsoft_365, Slack, Salesforce_MCP, Atlassian_Rovo, Claude_Code_Remote, Doc360_MCP |
| Notifications | push true, email false |

Observed runs

| Run | Session ID | Fired (UTC) | Finished (UTC) | Duration | Status |
|---|---|---|---|---|---|
| 2026-09-10 | REDACTED | 04:03:47.960 | 06:29:26.092 | 2h 25m 38s | SUCCEEDED |
| 2026-09-11 | REDACTED | 04:03:47.620 | 04:37:32.369 | 33m 44s | SUCCEEDED |

Expected duration for the work performed: under 5 minutes.

Evidence — where the time goes

The task's instructions include a self-timing step: the run reads date -u at each boundary between its work steps. The 2026-09-10 run produced this:

| Step | Start | End | Duration |
|---|---|---|---|
| (run start → first connector call) | 04:04:05 | 06:25:41 | 2h 21m 36s |
| Email search | 06:25:41 | 06:25:49 | 0m 08s |
| Teams search | 06:25:49 | 06:26:01 | 0m 12s |
| Slack searches (4 calls) | 06:26:01 | 06:26:30 | 0m 29s |
| Slack channel reads (5 parallel + 3 thread reads) | 06:26:30 | 06:27:24 | 0m 54s |
| Assemble and write output | 06:27:25 | 06:27:52 | 0m 27s |
| Total | 04:04:05 | 06:27:52 | 2h 23m 47s |

Roughly 30 tool calls across eight turn boundaries completed in 2m 10s combined. One boundary consumed 2h 21m 36s.

The run's first clock reading was 04:04:05 UTC, 4m 5s after the 04:00 cron time — ordinary queueing, and not where the problem is.

The connector is not the cause

The stalled boundary sits immediately before the first mcp__Microsoft_365__outlook_calendar_search call, so the natural first suspicion is a slow Graph connector. Three things rule that out:

1. The same call, re-run on demand in the same session later that day, took 4.52 seconds (07:18:24.989 → 07:18:29.511 UTC).
2. Two other Microsoft_365 calls in the same run — outlook_email_search and chat_message_search — completed in 8s and 12s.
3. The stall is at a turn boundary, not inside a call. No tool call is in flight during the gap. The preceding turn had already returned its results; the next turn had not yet issued a request.

Every connector in the run behaved normally. The idle time contains no network activity at all.

Suspected trigger

The gap sits at the run's first turn boundary, immediately after a deferred tool-schema load (the ToolSearch step that loads MCP tool definitions into the session). Every subsequent turn boundary in the same session advanced in seconds. This points at the session not being scheduled for inference until something external attaches to it, rather than at any per-call latency.

User observation (not independently verified)

On the 2026-09-10 run, the account owner reported that the session appeared to stay paused until he opened the conversation in the Claude app, at which point it completed within four minutes. The timing is consistent with that — the stall ended at 06:25:41 and the run finished at 06:29:26 — but this correlation was noticed by the user, not instrumented, so it should be treated as a lead rather than a finding.

The 2026-09-11 run is a partial counter-example worth weighing: it completed in 33m 44s, still far longer than the work requires but without an hours-long stall, and the owner was travelling that morning. So the dependency, if it is one, may be probabilistic or timeout-bounded rather than a hard block.

Why this is not a duplicate of existing reports

Two open-source issues look superficially similar and are both about a different failure mode:

• #36131 — Cowork scheduled tasks don't fire unless the Cowork view is focused. Local desktop tasks; the scheduler never starts them. Closed as not planned.
• #44128 — Scheduled tasks don't run when the desktop app is closed, then all fire at once on launch. Tasks not firing. Closed as duplicate.

In this report the task does fire, on time, server-side, and the platform records it as such. It then begins work and stalls partway through. That is a distinct defect in how a running cloud session is advanced, not in how tasks are scheduled.

What would confirm it

Server-side timestamps for each model-inference request in session REDACTED between 04:04:05 and 06:25:41 UTC. If there are no inference requests in that window, the session was idle and the scheduler is the cause. If there are requests that took hours to return, it is inference-side instead. That single piece of telemetry separates the two.

What Should Happen?

Expected: total duration ≈ sum of tool-call latencies plus model time.
Actual: total duration is dominated by one idle gap at the first turn boundary.

Error Messages/Logs

Steps to Reproduce

1. Create a Cowork scheduled task with persist_session: false and no device binding, on a weekday cron.
2. Attach several MCP connectors so the session begins with a deferred tool-schema load.
3. Let it fire while the desktop app is closed and the user is away.
4. Compare the platform's recorded fired_at/finished_at against the actual tool-call latencies inside the run.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.49585.0

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Why this is not a duplicate of existing reports

Two open-source issues look superficially similar and are both about a different failure mode:

• #36131 — Cowork scheduled tasks don't fire unless the Cowork view is focused. Local desktop tasks; the scheduler never starts them. Closed as not planned.
• #44128 — Scheduled tasks don't run when the desktop app is closed, then all fire at once on launch. Tasks not firing. Closed as duplicate.

In this report the task does fire, on time, server-side, and the platform records it as such. It then begins work and stalls partway through. That is a distinct defect in how a running cloud session is advanced, not in how tasks are scheduled.