[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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](https://github.com/anthropics/claude-code/issues/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](https://github.com/anthropics/claude-code/issues/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

```shell

```

### 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](https://github.com/anthropics/claude-code/issues/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](https://github.com/anthropics/claude-code/issues/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.

No repository file or test is named in the report. Start by checking server-side inference-request timestamps for the session during the reported gap, then compare them with the recorded tool-call timings; done means distinguishing an idle scheduler gap from slow inference and identifying the relevant session-advancement component.

Rédigé par le modèle d'indexation à partir du texte de l'issue.