#19543·lobehub

[Bug] lh agent run never exits on the default WebSocket transport (--sse exits normally), CLI 0.0.54

Author: LucaLin233Created Sep 13, 2026Updated Sep 15, 2026

What happened?

lh agent run uses the WebSocket gateway by default — per --help, the flag --sse exists to "Force SSE stream instead of WebSocket gateway". With that default transport, the process never returns after the run has completed.

  • Non-interactive use (lh agent run ... > out.json 2>&1, e.g. over ssh without a TTY): the run itself completes server-side (the assistant reply is written to the topic), but the CLI process stays alive forever — it has to be killed, and no exit code is ever produced, so it cannot be used in scripts.
  • Adding --sse makes the exact same command finish and return a normal exit status.
  • Under a pseudo-TTY, the WebSocket session is torn down by the remote side and again no usable exit status is obtained.
  • Gateway auth is fine: the CLI prints WebSocket connected / Authentication successful / CONNECTED, and lh status reports CONNECTED — so this is not an auth problem.

How to reproduce

  1. lh agent run -a <agent-id> -p "hello" > /tmp/out.json 2>&1 (no --sse), ideally over ssh without a TTY.
  2. Wait until the reply shows up server-side (agent_operations.status = done, assistant message written).
  3. The process is still running (pgrep -af "lh agent run") and never exits.
  4. Repeat the same command with --sse: it exits normally with code 0.

What it should be?

The CLI should exit once the run reaches a terminal state, just as it does with --sse. The transport flag should not change the process lifecycle.

Additional information

  • @lobehub/cli 0.0.54 (latest on npm at the time of writing), self-hosted LobeHub v2.2.17.
  • There is no configuration to persist the transport choice — --sse (or wrapping the call in timeout) is only a workaround, and it is easy to get wrong in scripts.
  • I searched for an existing report before filing (keywords: lh agent run hang / not exit / websocket, cli websocket stream) and found none. #14780 and #14763 look related in the title but are about gateway signature verification, which is a different problem.