Faithful ANSI replay, not plain text
Captured logs are the raw PTY byte stream, replayed into a disposable read-only xterm with 200k-line scrollback. Colors, cursor moves and formatting render exactly as they did live.
docsreliability
Bracket a run. Replay it later.
Wrap any terminal in START and END, tee every byte to disk, and reopen the exact ANSI output later in a read-only viewer. No scrollback limits, no copy-paste, nothing leaving your machine.
overview
Run Logging lets you manually bracket a slice of one terminal's life and capture its raw output into a per-run log file on disk. Each run gets a persisted metadata record — status, duration, exit code, byte size, working dir, originating slot — and a saved log you can reopen later in a faithful read-only ANSI viewer. It answers "what did that command actually print three runs ago" without scrollback limits or copying output out by hand. Automatic agent-driven capture is on the roadmap; today, capture is explicit and per-terminal.
- Raw PTY byte stream replayed into a 200k-line read-only xterm — colors and cursor moves intact
- Records and logs live only under the app config dir: runs.json and runs/<id>.log
- Zero network calls, zero telemetry — capture never leaves your machine
- Leftover active runs are reconciled to interrupted on startup, never left dangling
- History capped at 200 closed runs; viewer tail-caps reads at 4 MB
- Deleting a run removes both its metadata record and its log file from disk
why it matters
Fully local, no telemetry
Every run record (runs.json) and log file (runs/<id>.log) lives under the app config dir. Nothing is uploaded; the feature makes no network calls, consistent with 13x's no-cloud stance.
Survives crashes honestly
Recording writers live only in memory. On startup, any run still marked active is reconciled to interrupted rather than silently left dangling — you always see the true outcome.
Agent- and slot-aware
A run snapshots the originating rig slot's id, name and role at START, so the record stays labeled (e.g. DEV, AGENT) even after the session is gone.
Bounded by design
Closed-run history is capped at 200 records and pruned on startup and after each run. The viewer tail-caps reads at 4 MB, so a multi-hour or multi-GB capture never blows up memory or the IPC channel.
Strictly read-only
The viewer disables stdin and disposes its xterm on close, leaving no residual capture. You replay output; you never accidentally type into it.
how it works
01
Hit REC on a live terminal
On a live terminal card, click REC. 13x snapshots the session, creates runs/<id>.log, registers a live writer, and persists an active run record auto-labeled with the slot name and local start time.
02
Every byte is teed to disk
The per-terminal reader thread tees each raw output chunk into the run recorder, writing only while a run is active for that exact terminal incarnation — a cheap no-op otherwise, and generation-gated so a stale reader can't bleed into a fresh run.
03
Hit END to finalize
The same button shows END while recording. Click it to flush the log and close the run as completed with its final byte count and duration. If the terminal dies mid-run, 13x finalizes it as completed or interrupted automatically.
04
Reopen the run later
In the sidebar RUNS section, click any run row to open the read-only viewer. It flushes the live writer, returns the trailing 4 MB of log, and streams it into a fresh xterm alongside metadata — status, duration, exit code, slot role, cwd, started→ended times.
05
Rename, delete, or close
Rename a run inline, or DELETE to permanently remove its record and on-disk log. Close with CLOSE or Esc — the temporary xterm is disposed so nothing is left behind.
faq
Does capturing a run send anything to the cloud?
No. Run records and logs are written only under the app config dir, and the feature makes no network calls — consistent with 13x's no-cloud, no-telemetry design.
Can 13x auto-start runs for my agents?
Not yet. Capture is manual: you click REC/END on each terminal, and there's no global shortcut to start or stop. Automatic agent-driven capture ('Agent run logging') is a roadmap item, not shipped.
What happens to a run if the terminal or app crashes mid-capture?
You still see the truth. Writers live in memory, so on startup any leftover active run is marked interrupted. If the terminal exits while recording, the run is finalized as completed (with exit code) or interrupted.
How much of a long log can I actually see?
The viewer renders the trailing ~4 MB with a truncation notice; the full file stays on disk. History keeps the newest 200 closed runs, and the sidebar lists the 15 most recent.
get started
one project. many shells. zero noise.
13x is local-first and free of telemetry — your code, commands and shells never leave the machine. Join the waitlist for the next build.
related