Desktop Inspector Chat

The desktop Machines tab exposes a per-machine inspector chat. Every message goes straight to the agent on the target machine; the local LLM never sees it. This is the high-fidelity way to interrogate a remote agent.

What it is

In the Desktop client’s Machines tab, click a machine to open its inspector. The inspector includes a chat pane where every message sent is routed via remoteagent.AskStream directly to the target machine’s daemon — no local model in the middle.

The remote agent’s reply is the answer.

Why direct pipe

Two reasons:

Fidelity — the local LLM cannot paraphrase, summarize, or hallucinate the remote answer.
Latency — fewer hops mean tokens stream through immediately.

Use the inspector when you want the remote agent’s exact reasoning, not your local agent’s interpretation of it.

How session IDs work

The frontend mints session IDs of the form:


machine_<uuid>_<hex>

The desktop chat service decodes the prefix, threads TargetMachineID into chat.Optional, and runSession sees the non-empty machine ID. That triggers remoteagent.AskStream instead of running the local agent loop.

This is invisible to you as a user. Just click the machine and start typing.

Streaming behavior

Tokens arrive as chat:chunk events. Final text is persisted via Session.RecordTurn, so:

The transcript survives if you close the inspector and reopen it.
cmdop chat --resume <session-id> (when you want a CLI view of the same conversation) replays from the saved turns.

Event types you may see flow through the SDK if you watch the wire:

TOKEN — token-by-token output.
TOOL_START, TOOL_END — the remote agent invoked a tool.
THINKING — extended-thinking spans (where the model supports it).
ERROR — remote-side failure.
CANCELLED — caller hit the cancel button.

What you can do

The same agent surface as remote chat:

Ask questions (“what’s running on port 8080?”).
Run tools (subject to receiver’s permissions.yaml).
Upload files via the inspector pane (transferred via the agent’s file tools).
Browse session history.

Compared to `cmdop chat --machine X`

Two paths exist; they serve different needs:

Surface	Path	What runs	Best for
Desktop inspector chat	A	Direct pipe to remote agent	Fidelity. The remote answer is the answer.
`cmdop chat --machine X`	B	Local LLM with remote dispatchers	”Front desk” model that talks for you.

Path B keeps the local LLM and trims tools to remote dispatchers (drops read_file / write_file / grep / glob / list_dir for safety). Path A bypasses the local LLM entirely.

Resuming

Both paths persist transcripts via Session.RecordTurn. Detach the desktop tab → reattach later → conversation restored. The CLI view (cmdop chat --resume <session-id>) joins the same conversation from another surface.

When to use which

Investigating an incident on a remote box — Path A. You want the remote agent’s view, not your local agent’s spin on it.
Running an interactive workflow that touches multiple machines — Path B with ask_agents for fan-out.
Pair operating — Path A; the inspector is multi-client, your colleague can attach to the same session.

When the Machines tab shows a chat icon next to a machine, that’s the direct-pipe inspector. The local LLM is bypassed.

Receiver permissions still apply. If the target machine’s permissions.yaml denies a tool, your inspector chat sees the denial.