[Bug] CLI daemon startup reports success before attempting gateway connection; initial failure is not surfaced

Client Type

Other — @lobehub/cli, lh connect --daemon

Operating System

macOS (Apple Silicon)

Deployment Platform

Self hosting Docker; CLI runs on the macOS host.

Version

Installed CLI package: 0.0.52 (read from its installed package.json). The same startup ordering is present in current canary commit bc4bfdff7692697f6077795a9a0e520e8e444c56.

Browser

Not applicable — terminal/CLI.

What happened?

lh connect --daemon --gateway <unreachable-gateway-url> reports Daemon started (PID …) and returns to the shell before it attempts to connect to the gateway. The connection then fails with EHOSTDOWN, but the initial invocation does not surface that failure. It only directs the user to a log and a separate status command.

Strictly speaking, the daemon process did start, so the message is not a false statement about process creation. The UX problem is that connect completes with a startup-success message without clearly saying that gateway connectivity/authentication is still pending or has failed. Users cannot tell whether the requested connection is usable from that invocation.

Observed terminal sequence (addresses, paths, and PID redacted):

$ lh connect --daemon --gateway http://<unreachable-host>:8787
[INFO] Daemon started (PID <pid>).
[INFO]   Logs: <home>/.lobehub/daemon.log
[INFO]   Run 'lh connect status' to check connection.
[INFO]   Run 'lh connect stop' to stop.

# Subsequent connection/status output:
[ERROR] WebSocket error: connect EHOSTDOWN <unreachable-host>:8787
[ERROR] Connection error: connect EHOSTDOWN <unreachable-host>:8787
[INFO] WebSocket closed: code=1006 reason=
[ERROR] FAILED - Connection closed by server

How to reproduce it?

1. Use an authenticated CLI profile with no already-running connect daemon.
2. Select a gateway URL known to be unreachable from that machine.
3. Run lh connect --daemon --gateway <url>.
4. Observe that the command prints Daemon started before the initial network connection result is known.
5. Inspect the daemon log / connection status to see the connection failure.

The reported environment demonstrated EHOSTDOWN. DNS failure, refused connections, timeouts, and authentication rejection are useful additional regression cases; they were not all manually tested for this report. The initial shell exit code was not captured in the reported terminal session.

What it should be?

Distinguish process started, connecting, and connected/authenticated.

Prefer waiting for an initial gateway connection/authentication result with a bounded timeout. If initial connectivity is required for success, surface the error and return a non-zero exit code. If daemon mode intentionally keeps retrying while offline, clearly report that the daemon is running but the gateway is not connected, and state the retry policy. In either design, avoid leaving only a successful-looking startup message for a failed initial connection.

Code evidence

• handleDaemonStart awaits spawnDaemon() and then prints Daemon started.
• spawnDaemon resolves on the child's startup-ready IPC message. It already handles startup errors/exits/timeouts.
• The child calls await reportDaemonStartupReady() before await client.connect().
• GatewayClient.connect() invokes doConnect() and returns; its Promise does not wait for WebSocket/authentication readiness. Merely moving reportDaemonStartupReady() below the current await client.connect() would therefore not establish the required readiness guarantee.

Existing startup-preflight error handling should be preserved. The missing boundary is reporting the first gateway connection/authentication outcome to the initiating command. A regression test should keep a daemon process alive while its initial gateway connection fails and assert the parent command's output and chosen exit-code semantics.

Searched open and closed issues for "Daemon started", "startup-ready", daemon/connect, daemon/startup, and gateway/unreachable; no matching issue found. This report contains no credentials or private endpoint identifiers.