lh agent run stream completion ignores waiting_for_human and reports "Agent finished"
Observed in source
Reviewing #19597 at 07c31121, I found a mismatch between stream completion and run completion. This is a source-level finding, not an end-to-end reproduction against a deployment.
When either stream helper receives agent_runtime_end with data.reason: "waiting_for_human", the non-JSON CLI output says ✓ Agent finished. The helper then returns normally without setting a failure exit status, even though the run is waiting for human input.
Evidence
In apps/cli/src/utils/agentStream.ts:
renderEndreadsstepCount,usageandcost, but notdata.reason(484-500).- The SSE handler calls it in non-JSON mode at
105, then returns at107. - The WebSocket handler calls it in non-JSON mode at
331, then resolves at336. - JSON mode skips
renderEnd, but these end-event branches still complete normally.
On the server side, STREAM_END_STATUSES includes waiting_for_human alongside done, error and interrupted. When the state first transitions from outside that set into it, AgentRuntimeCoordinator publishes the end event with reason: state.status.
The --no-headless help text also says "wait for human approval on tool calls" (apps/cli/src/commands/agent.ts:358-359). If approval is required and the stream ends at that point, the current wording does not explain that the command returns rather than continuing to wait.
Expected behavior
Distinguish stream completion from successful run completion:
- Do not label
waiting_for_humanasAgent finished. - Define the exit-status contract for parked and unsuccessful runs in both output modes.
- Make the
--no-headlesshelp text match that contract.
Passing the end reason back to the command is one possible approach, not a required implementation.
#19597 already distinguishes a parked run in the polling fallback; this issue concerns the live-stream end-event path.
Related
- #19597, which addresses the hangs reported in #19543.
- Companion follow-up: polling fallback exit statuses and missing-result wording.
Source: lobehub/lobehub