Cloud Agent: turn ends silently when the environment/process is stopped — no notice, no reason, no resume

[maphew]

Summary

When a Cloud Agent run is interrupted by infrastructure (e.g. the control plane stops the sandbox/environment), the turn ends silently: the thread just stops in the middle of the job with no note, no error, and no reason shown. The cause is actually recorded in the transcript, but neither the web app nor the mobile app surfaces it, and there is no way to resume from where the run stopped.

What the user sees

A thread that was actively working stops mid-task. No "stopped" notice, no error bubble, no sandbox/recovery message. The composer is enabled again, but nothing explains what happened or offers to continue the interrupted step.

Evidence from an affected session

Session ses_f92a893afffeHzcYpsm4Cwr8aQ (2026-09-04, single autonomous turn, no user stop was ever pressed):

• The final assistant message started at 18:54:43 UTC and was finalized 7.7 s later with zero parts and zero tokens, carrying:
  { "name": "MessageAbortedError", "data": { "message": "Aborted" } }
  In the CLI this error is written when an in-flight assistant message is finalized because the run's Effect fiber was interrupted (Effect.onInterrupt -> AbortedError in packages/opencode/src/session/prompt.ts). It means the process/run was stopped mid-request — not a model error and not a tool failure.
• The provider/gateway link was unhealthy before the end: three individual steps took 4.5 min, 13.8 min, and 37.8 min for what normally takes ~10–20 s. The 37.8-min step completed at 18:49:47, a normal ~10–20 s cadence resumed for ~5 minutes, then the abort fired at 18:54:50 — 5 min 3 s after the stalled step completed. The Cloud Agent control plane's idle-stop deadline is 5 minutes (DEADLINE_MS.idleStop = 5 * 60_000 in services/cloud-agent-next/src/sandbox-control/deadlines.ts); when it fires it destroys the sandbox, killing the kilo process mid-step.
• Net result: a ~2 h autonomous job was stopped with no user-visible explanation, and the container was gone. This session ran on a legacy agent_ container, which does not get the sandbox-status indicator at all, so nothing in the UI hinted at the lifecycle stop.

Why it is silent

• The CLI is behaving as designed internally: on process termination it marks the open assistant message aborted and cannot append anything else.
• The user-facing contract only covers deliberate stops — .specs/cloud-agent-session.md: "Stop MUST end the current turn, tell the user the session was stopped, and re-enable the composer." There is no equivalent for infrastructure aborts. Clients render the zero-content aborted message as nothing, so the thread looks like it "just quit".

Desired behavior

1. When a turn ends without normal completion for an infra reason (aborted in-flight message / environment stop / connection loss), append an explicit user-visible notice stating the reason (e.g. "Environment stopped after inactivity" / "Connection lost") instead of ending silently.
2. Offer a Resume action on that notice that continues from the aborted step — the CLI already supports resuming from an aborted tail message.
3. Show the sandbox lifecycle state (stopping / stopped / error) inline with the interrupted turn, including for legacy sessions, rather than leaving the thread looking frozen.
4. Surface the underlying termination reason (expandable) so this is triageable without pulling Durable Object / wrapper logs.

Context

• Reproduces with any long autonomous Cloud Agent job that crosses the idle-stop/sleep/heartbeat-gap boundaries; this instance was observed in the Android app.
• Session transcript export is available on request.
• Legacy (agent_) sessions have no sandbox status UI at all (spec: "Legacy agent_, unresolved, demo, remote, and read-only sessions MUST NOT show the indicator"), which makes the silent end the default for them.

Related

• [Gastown] No proactive GitHub token refresh — installation tokens (ghs_) expire every hour, stranding agent work on 401 #4393 — different trigger (GitHub token expiry) but same symptom family: agent work stopped by infrastructure with weak surfacing.
• Code Review is reported as successful even when the AI model fails #5630 — UI reports success when the model failed (opposite false-positive).
• Constantly/sporadically stops mid output with no error message kilocode#13061 and #12741 — desktop CLI counterparts of "stops/aborts with no error shown".