← Docs
RUNNING TASKS · VERSION 1.0

Watching the live console

The dashboard's live console stream is the primary way to see what an agent is doing right now.

When an agent is working, Build Station streams its entire console — exactly what you'd see if you were sitting at the terminal next to it — to the Meshly Build dashboard in real time. That's where you watch, intervene, or just keep an eye on things.

Where to find the live stream

On the dashboard, open the task that's running. The Console tab shows the live stream. It updates every ~500 ms.

What you see

Claude Code runs as a full TUI inside the agent's session. The stream shows that TUI verbatim:

  • Claude's current "thinking" status, token counter, model selection.
  • Tool calls (file reads, edits, bash commands).
  • Tool results.
  • The agent's natural-language responses.
  • Any errors or prompts (though headless agents auto-approve permissions, so you rarely see those).

ANSI colors and TUI redraws come through correctly. The dashboard renders them like a real terminal.

What you can do from there

  • Watch passively. Most common. Verify the agent is on the right track without interrupting.
  • Cancel the task. Dashboard has a Cancel button on the task. Build Station receives the cancel signal, kills the Claude session cleanly, and the task moves to Blocked.
  • Send a message. If your dashboard exposes the inject-input feature, you can type a message to the agent. Build Station forwards it as stdin to the running Claude session. Use sparingly — Claude can get confused by mid-task instructions.

How streaming works

Build Station's tmux backend (macOS) or headless backend (Windows) captures the agent's pane content every 500 ms and emits the delta to the backend over a WebSocket. The dashboard listens on the same WebSocket and renders.

This is a one-way fire-and-forget stream from Build Station to the dashboard. If the WebSocket drops, the agent keeps running locally — only the live view is interrupted. The task still completes normally and the result lands in the dashboard via the MCP server's complete_task call.

Note: The stream is the watch view, not the source of truth

Activity entries, task status changes, commits — all those go through the MCP server, not the console stream. If you only care about results, ignore the stream. The stream exists for live observability.

When the stream isn't working

You should see output within a second or two of the agent starting. If the console stays blank or shows only the initial bash echo:

1. Check the tray status

Hover the tray icon. If it says "1 agent running" but the console is blank, the local capture is working but the upload isn't.

2. Check the log viewer

Settings → Logs → Open in-app log viewer. Filter for console_feed. Errors here usually mean a firewall or proxy blocking the WebSocket connection to the backend.

3. Try the local log file

Build Station also writes the agent's console to a local log file (one per task) as a fallback. Settings → Logs → Open log directory. Per-task logs are named by task ID.

See Troubleshooting for the full debug flow.

Why streaming might lag

A few normal causes:

  • Heavy TUI redraws. Claude periodically refreshes its status bar; on very slow connections the deltas can buffer briefly.
  • Network roundtrip. Sub-second is typical; cross-continent links can add a noticeable but small delay.
  • Backend load. During very busy periods the broadcaster on the backend may batch updates more aggressively.

These are all fine — the stream catches up quickly once the network breathes.

Local log files

Every agent session also writes its console output to a local log file on disk, in addition to streaming. Useful if you want to grep through history after the fact, or share output with someone who doesn't have dashboard access.

Location:

  • macOS: ~/Library/Application Support/meshly-station/logs/sessions/
  • Windows: %APPDATA%\meshly-station\logs\sessions\

One log per task. Files are named after the task ID and rotated daily.

Still stuck?

If this page did not answer the question you arrived with, tell us what it was. That is a documentation bug on our side, and we would rather fix it than have you guess.