Remote Log Fetch

Three log sources are reachable from the hive CLI for debugging - especially useful when the device producing the logs is a phone or remote machine you don't want to open a shell on.

Source	What it is	How the daemon gets it
daemon	hived.log - the daemon's own tracing output	Reads the file directly (or forwards to a cluster peer)
app	hive-app.log.YYYY-MM-DD - the Hive desktop/mobile app's Rust-side log	Asks a connected app over its WebSocket
frontend	The Vue WebView's diagnostics ring buffer (viewport, terminal, lifecycle)	Asks a connected app; app reads its in-WebView buffer

CLI usage

# Daemon log of whichever node you connected to:
hive logs daemon --lines 200

# Daemon log of a specific cluster peer:
hive logs daemon --node <node-uuid> --lines 1000

# List connected clients plus known cluster nodes:
hive clients ls

# App-backend log of a specific app client (use connection_id from `clients ls`):
hive logs app --client <connection-id> --lines 500

# Frontend diagnostics buffer of the same app client:
hive logs frontend --client <connection-id> --lines 500

hive clients ls prints connected clients first:

Connected Clients
=================
CONNECTION_ID                          KIND     PLATFORM       PEER                   NAME
12c4a8f3-...-91e6                      app      android        100.64.0.7:51422       Pixel-9
4ab8...                                cli      linux-x64      100.64.0.4:55001

The connection_id is what you pass as --client to the app / frontend subcommands. The same command also prints a Cluster Nodes table; use those node IDs with hive logs daemon --node <node-id>.

Wire protocol

New ClientMessage variants:

• ListConnectedClients → ServerMessage::ClientList { clients }
• GetAppLog { client_id, lines } → ServerMessage::AppLog { client_id, lines, error }
• GetFrontendDiagnostics { client_id, lines } → ServerMessage::FrontendDiagnostics { client_id, lines, error }

App clients additionally:

1. Self-identify in Auth with client_kind: Some(ClientKind::App { platform, app_version }). CLI uses ClientKind::Cli { platform }.
2. Reply to daemon-pushed ServerMessage::AppLogRequest / FrontendDiagnosticsRequest with the matching ClientMessage::AppLogResponse / FrontendDiagnosticsResponse, correlated by request_id.

The daemon enforces a 10-second timeout on the round-trip; missing/disconnected apps surface as AppLog { error: Some("client … did not respond within 10s") } rather than hanging the CLI.

Behaviour and limits

• No device-side prompt. A CLI that holds the daemon's token can fetch logs from any currently-connected app on that daemon. The mental model: anyone who can run hive ls could already read sessions; logs are no more sensitive.
• App must be connected. If the app is backgrounded long enough that its WebSocket has been torn down, hive logs app returns an error. Re-open the app and retry.
• Frontend buffer is bounded. The Vue diagnostics ring buffer holds the most recent 1500 entries (~ last few minutes of activity for a busy session). For longer history use the in-app Logs → Frontend view, which is the same buffer rendered locally.
• No cross-cluster app routing. App-log fetch hits the daemon the app is connected to; it doesn't currently chase apps that authed to a different cluster peer. Daemon-log fetch does support --node cluster forwarding.
• CLI connections show up too. hive clients ls lists cli-kind connections for completeness, but hive logs app|frontend --client <cli-id> will return an error - CLIs don't keep logs the daemon could fetch.

Related

• Mobile Diagnostics - the in-app Logs view that consumes the same sources without going through the CLI.
• Protocol - broader wire-protocol reference.