Build Station writes structured logs as it runs — useful when something's not working and you need to understand what it's doing. There's a log file on disk, plus an in-app viewer that streams the same data in a searchable window.
Where log files live
| Platform | Path |
|---|---|
| macOS | ~/Library/Application Support/meshly-station/logs/ |
| Windows | %APPDATA%\meshly-station\logs\ |
Files there:
meshly-station.YYYY-MM-DD.log— Build Station's own structured tracing output. Rotates daily; rotated files are kept ~14 days.sessions/<task-id>.log— one log per agent session, containing the agent's full console output. These are the same content as the live console stream, written locally as a fallback.
The in-app log viewer
Settings → Logs → Open log viewer. A scrollable window opens streaming tracing output in real time.
Controls:
- Level filter — show only
info,warn,error, or everything (trace). - Module filter — narrow to a specific subsystem (e.g.
dispatch,console_feed,mcp_config). Useful when you know which area is misbehaving. - Search — substring filter over the visible lines.
- Pause / Resume — freeze the stream while you read a chunk.
- Copy selection — copy lines for pasting into a bug report.
The viewer reads from the same source the on-disk log writes to. Closing it doesn't stop logging — Build Station keeps writing to disk regardless.
Adjusting log level
Settings → Logs → Log level. Options:
| Level | When to use |
|---|---|
| error | Only errors. Very quiet. Good for production-style operation where you don't want noise. |
| warn | Errors plus warnings (e.g., retry attempts, MDS env fetches degraded). |
| info | Default. Spawn events, completion events, sync summaries, queue activity. |
| debug | Adds per-poll-tick output, MCP config writes, finer-grained dispatcher events. |
| trace | Everything. Includes per-message wire activity. Very noisy — only use briefly when investigating. |
Changes take effect immediately — no restart needed. The setting persists across launches.
Warning: Trace is loud
At trace level a single hour of running Build Station can produce hundreds of MB of log. Useful for capturing a hard-to-reproduce bug, but turn it back off when you're done — the disk space and log rotation tail get expensive.
Privacy of log content
Logs are local. Build Station never uploads its tracing output anywhere.
Log content contains:
- Task IDs, agent names, project IDs (no task content).
- HTTP method + path + status code for backend calls (no body content).
- MCP server URLs (no bearer tokens — those are redacted before logging).
- Console feed bookkeeping events (NOT the actual agent output — that goes to the per-session log file).
Agent console output, including any file paths or content the agent prints, lives in the per-session log file under logs/sessions/. Treat those with the same care as the project files themselves.
Sharing logs for support
When you file a bug or ask for help:
1. Reproduce with debug or trace level
Settings → Logs → set level to debug (or trace for hard bugs) → reproduce the issue.
2. Find the relevant time window
Use the in-app viewer's search or the on-disk log file. Note the timestamp range where the issue happened.
3. Trim to just that window
Don't share entire log files unless asked — they often contain hours of unrelated output. A few minutes around the issue is plenty.
4. Redact if needed
Logs shouldn't contain credentials (they're redacted) but they DO contain task IDs and project names. If those are sensitive in your context, edit before sharing.
Per-session logs
The agent's console output is written to logs/sessions/<task-id>.log. Each task gets its own file. The format is the raw terminal output exactly as it appeared on the agent's TUI.
Useful when:
- The live console stream wasn't working and you want to see what the agent actually did.
- You're investigating after the fact and the dashboard's saved console history isn't enough.
- You want to grep for a specific error or file path the agent touched.
Per-session logs are not auto-deleted — they accumulate. Settings → Logs → Open session logs folder to manage them manually. Most users won't ever need to look at these unless something specific went wrong.