[BUG] Cloud routines stall before their first turn: 'Claude Code process started', then no init, no result - while other routines on the same environment run green

Some cloud routines never reach their first turn. Others on the same account and the same environment run green every day. Nothing the API exposes distinguishes them.

Likely the same underlying fault as #83709, which reports it from an independent account, environment and model.

Symptom

Since 17 August 2026, six of my scheduled cloud routines have fired repeatedly and produced zero turns. Every failure looks the same: the sandbox allocates, the repo clones, Claude Code process started appears, and then nothing.

A healthy run emits init: model=... cwd=... about five seconds after that line. No failed run has ever emitted it, so the agent never reads its prompt.

Meanwhile two other routines on the same account, in the same environment (env_01EVmfW3Qv9jgYjxaZzk28ed), created through the same API, have run green throughout: a weekday promote routine and a weekly vault health check.

The split is by routine, not by anything I can change

I first thought the discriminator was time of day, because all 13 failures fell between 04:25 and 06:11 UTC and all 6 green runs fell at 09:04 UTC or later.

That is now disproved. I built a throwaway routine whose entire prompt is "run git log --oneline -1 and stop" and scheduled it for 10:05 UTC, inside the green window. It stalled with exactly the same signature (session cse_01UqdEJuAibcg3Zmq5MUV2EE, 22 Aug 10:05:56 UTC). The same diagnostic had already stalled at 04:42 UTC. Hour of day makes no difference.

Ruled out by experiment

Each attribute transplanted from a green routine onto a stalling one:

| Attribute | Test | Result |
|---|---|---|
| Model | Same trivial diagnostic on claude-opus-5, claude-sonnet-5, claude-opus-4-7 | All three stalled |
| Routine config | Copied the green routine's outcomes, autofix_on_pr_create, tool list and notifications onto a failing one | Stalled |
| Prompt content | A routine whose entire prompt is git log --oneline -1 | Stalled |
| Stale stored event | That diagnostic was created minutes before it first fired | Stalled |
| Creation path | Every routine reports created_via: http_api | No difference |
| MCP connectors | Routines with mcp_connections: [] stall; routines with seven connectors stall | Not the discriminator |
| Repo-side hooks | Neither repository tracks a .claude/settings.json | Nothing runs at session start |
| Time of day | As above | No difference |

The failure signature changed on 21 August, with no change on my side

17-20 Aug the runs failed loudly, about four seconds in:

env[error]: Claude Code execution failed
result: error_during_execution is_error=true turns=0 duration=0s

From 21 August onward they fail silently: no error event, no result event, the worker goes idle and the run never ends. Same absence of init: either way, so I read it as one fault with two presentations, and something moving platform-side in this path during that window.

Note that #83709 reports a third presentation: their runs report "Completed". Mine either error at four seconds or hang forever.

Failing sessions

Every failing session I have an id for: the six maintenance routines plus three throwaway diagnostics I created to isolate the cause. Repos are makappen-collab/fire-assessor-os and makappen-collab/cleaner-os.

| Session | Fired (UTC) | Model | Mode |
|---|---|---|---|
| cse_01DHxhDvQZtomekP1xoM7d7b | 17 Aug 05:14 | opus-5 | loud |
| cse_014sT96U3fquz3HCFCxkVqBi | 18 Aug 05:11 | opus-5 | loud |
| cse_0122581VoxY7ShaD7npGU4FD | 19 Aug 05:06 | opus-5 | loud |
| cse_018NYLV1BcZY11ueHGwpr3Sj | 20 Aug 05:04 | opus-5 | loud |
| cse_01TiwgwZoYboMZXPyq327f4a | 21 Aug 05:05 | opus-5 | quiet |
| cse_0118aQTRPXXkyeK44NZxuaJM | 21 Aug 06:11 | opus-5 | quiet |
| cse_01Ap9wcaiXbte4bR8w7RDMgY | 22 Aug 04:25 | opus-5 | quiet |
| cse_01HJWzMxwiJDqFFsUdLhRujg | 22 Aug 04:34 | opus-5 | quiet |
| cse_01X7deMjhHGkvmBhmcYE81gX | 22 Aug 04:42 | opus-5 | quiet |
| cse_01Qn9w4nYrwJhXsotozWEGPy | 22 Aug 04:48 | sonnet-5 | quiet |
| cse_016jbLXYxYnwcNBQ7zfpb4vj | 22 Aug 04:48 | opus-4-7 | quiet |
| cse_01UqdEJuAibcg3Zmq5MUV2EE | 22 Aug 10:05 | opus-5 | quiet |

A healthy run for comparison: cse_01MnLaGvYR5JT4cWrwG9gyT6, 21 Aug 11:20 UTC, same environment, same repo, opus-5. 16 turns, 168 seconds, success.

One unexplained event

The 10:05 stall carries an mcp_auth_required event before it goes quiet. That diagnostic carries seven connectors, so this may relate to #83894 (tools marked requiresUserInteraction stalling an unattended run).

It cannot be the whole cause here: the six maintenance routines report mcp_connections: [] and stall identically. I verified that against the API rather than from my own notes.

What would help most

The runner-side reason those sandboxes never emit init:. From outside, the run log stops at Claude Code process started and there is nothing further to inspect. I have exhausted every attribute the API lets me read or change.