embedded run timeout: runId=<...> sessionId=<...> timeoutMs=600000

There were also timeout-related entries such as LLM request timeouts around the same period.

### Investigation notes

From tracing the bundled code in 2026.3.8, this does not look like a simple frontend-only issue.

What I found:

- Control UI chat finalization appears to depend on lifecycle terminal events (phase === "end" or "error")
- the embedded timeout path appears to call abortRun(true) / activeSession.abort()
- that timeout path does not appear to directly emit a terminal lifecycle event itself
- terminal lifecycle emission seems to depend on the embedded subscription path receiving agent_end
- once agentRunStarted === true in webchat/control-ui, the UI path appears to rely on lifecycle terminal events and does not seem to have a fallback finalization path if those events never arrive

### Current hypothesis

There is an edge case where an embedded run times out or aborts after startup, but no terminal lifecycle event reaches Control UI.

That leaves the webchat/control-ui run stuck in a running state even though the run has already ended internally.

### What this does NOT look like

Based on local tracing, this does not currently look like:

- a simple early-return bug in dispatchInboundMessage()
- a frontend-only rendering issue
- an indefinitely blocked cleanup in flushPendingToolResultsAfterIdle() (that cleanup appears bounded)

### Possible areas to inspect

- embedded timeout/abort path in runEmbeddedAttempt(...) / runEmbeddedPiAgent(...)
- whether activeSession.abort() can bypass agent_end
- whether subscribeEmbeddedPiSession(...) can unsubscribe before terminal lifecycle is emitted
- whether webchat/control-ui should defensively finalize a started run when dispatchInboundMessage() settles but no terminal lifecycle event was observed

### Repro hints

In my case this happened in Gateway Dashboard chat after a long-running embedded run that eventually timed out. The UI had already shown completed tool/edit actions, but the run never left the Stop state.


### Expected behavior

After a timeout or abort, the Control UI should always receive a terminal state and the run should finalize as one of:

- completed
- aborted
- error

The UI should leave the `Stop` state.

### Actual behavior

After timeout:

- the run can stay stuck on `Stop`
- clicking `Stop` may do nothing
- the gateway can remain otherwise healthy
- the specific run/session appears zombied in the UI

### OpenClaw version

2026.3.8

### Operating system

Windows 11

### Install method

npm

### Model

openai-codex/gpt-5.3-codex

### Provider / routing chain

chat

### Config file / key location

_No response_

### Additional provider/model setup details

From tracing the bundled code in 2026.3.8, this does not look like a simple frontend-only issue.

What I found:

- Control UI chat finalization appears to depend on lifecycle terminal events (phase === "end" or "error")
- the embedded timeout path appears to call abortRun(true) / activeSession.abort()
- that timeout path does not appear to directly emit a terminal lifecycle event itself
- terminal lifecycle emission seems to depend on the embedded subscription path receiving agent_end
- once agentRunStarted === true in webchat/control-ui, the UI path appears to rely on lifecycle terminal events and does not seem to have a fallback finalization path if those events never arrive

### Logs, screenshots, and evidence

```shell