Sessions and Traces
Manage conversation history and inspect execution traces from the Dreadnode TUI.
Sessions and traces answer two different questions:
- session: what did this conversation say and how should I continue it?
- trace: what did the runtime, tools, and model actually do underneath?
Open these screens
Section titled “Open these screens”| Surface | Shortcut | Command |
|---|---|---|
| Session browser | Ctrl+B | /sessions |
| Trace browser | Ctrl+T | /traces |
| Raw spans view | none | /spans |
Session workflow
Section titled “Session workflow”Sessions are the conversational history attached to the current runtime.
Use the session browser when you want to:
- search older conversations by preview text or session id
- reopen a previous session
- start a clean one without leaving the TUI
- delete a session you no longer need
The browser is also where background session state becomes visible. It now shows badges for:
- running sessions
- sessions waiting for approval or human input
- unread activity
- queued follow-up messages
- stale replay state after reconnect
Use the command surface for session hygiene:
/newfor a clean session/rename <title>to make a thread recognizable/export [filename]to save the transcript/compact [guidance]to shrink a long thread before continuing
Sessions survive normal conversation flow because they reference the runtime identity rather than a single transient sandbox instance.
The session browser is the narrative surface. Search is optimized around conversation previews, agent or capability clues, and session IDs, not raw span mechanics.
When a non-active session needs approval or text input, the TUI does not steal focus. Instead, that session is marked as waiting in the browser and header/context surfaces. Switch into it, and the stored prompt is rendered immediately from session state.
Trace workflow
Section titled “Trace workflow”Traces are the inspection surface for what happened during execution.
Use /traces when you need to:
- inspect what tools were called
- follow execution after a complex agent turn
- compare runs inside the current project context
- move from “the answer looks wrong” to “what happened underneath?”
In practice, sessions are the narrative view and traces are the telemetry view. The trace browser is project-filtered inside your current workspace context, which is why it is the right next step after narrowing to the relevant project or runtime.
Use /spans when you want the local JSONL backing file for the active session itself. This is the
rawest inspection surface in the TUI: one row per exported span, with pretty-printed JSON for the
selected line and optional follow mode while a session is still producing spans.
That distinction matters:
/tracesis the remote OTEL-backed inspection surface/spansis the local JSONL backing file for the active session
When to use which
Section titled “When to use which”| If you want to know… | Use |
|---|---|
| what the assistant and user said | session browser |
| whether a previous thread should be resumed | session browser |
| what tools, spans, and internal execution happened | traces |
| what exactly was written to the local JSONL file | raw spans view |
| why a run or answer behaved unexpectedly | traces |
Continuity: session -> trace -> agents
Section titled “Continuity: session -> trace -> agents”These screens are meant to be used together.
1. Start with the session
Section titled “1. Start with the session”Resume the relevant conversation with Ctrl+B or /sessions when you need the transcript,
previous title, or continuation context.
2. Move to traces for execution detail
Section titled “2. Move to traces for execution detail”Open Ctrl+T or /traces when the question changes from “what did we say?” to “what actually
executed?”
That is where you inspect tool calls, spans, and runtime behavior for the same workspace and project context.
3. Move to Agents for wider pattern analysis
Section titled “3. Move to Agents for wider pattern analysis”Once you know which run or failure pattern matters, open Agents to:
- compare that behavior against the rest of the workspace
- query
otel_tracesand related telemetry tables directly - export CSV for structured follow-up
- inspect notebook-style aggregates that combine runs, spans, and evaluations
Practical debugging loop
Section titled “Practical debugging loop”| If the question is… | Do this |
|---|---|
| can I reopen the exact conversation? | use the session browser |
| did a long thread confuse the model? | use /compact [guidance] before continuing |
| which tool call or span failed? | open /traces |
| what does the raw exported span payload say? | open /spans |
| is this happening across more than one run? | move to Agents Charts or Notebook |
| do I need structured evidence? | export the transcript or Agents Data CSV, depending on the need |
Exporting the right thing
Section titled “Exporting the right thing”/export [filename]saves the conversation transcript- Agents
DataExport CSVsaves query results - the trace browser is for inspection and narrowing, not for transcript management
/spansis for local JSONL inspection, not workspace-wide trace search
What agents should assume
Section titled “What agents should assume”- Sessions reference the runtime, not one specific sandbox instance.
- Traces are workspace-scoped telemetry with the current project acting as a filter.
/compactchanges conversation context, not the underlying trace history.- Exporting a session transcript is different from exporting or querying telemetry.
- The standard operational path is session first, traces second, Agents third when the question broadens from one run to a pattern.