[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.

No source files or tests are named. Start by reproducing the failure with one of the listed sessions and compare its runner logs with the healthy session, focusing on the path between “Claude Code process started” and the missing init event. Done means identifying and fixing the runner-side cause and adding coverage for a run that reaches init instead of failing or hanging.

Written by the indexing model from the issue text.