Skip to content
Threads
A thread is a DAG of sessions tied together by intent
auto ยท 0.84originplanning sessionchild Aphase 1child Bphase 2child Cphase 3grandchildauto-detectedsolid edges = manual ยท dashed = auto-detected
๐ŸŒฑ
Origin
The seed session, usually a planning or roadmap session. A thread can have multiple origins.
๐ŸŒฟ
Child
A session that continues the work. Each child has a parent. Re-parent or promote to origin anytime.
๐Ÿ”—
Edge
The parent-to-child link. Manual edges are confidence 1.0. Auto edges carry a confidence score and a source chip.
Three ways to add a session to a thread
Path 1
๐Ÿงท
Session header
Open any session, click + Add to thread above the collections row. Pick an existing thread or create one with this session as the origin.
Path 2
๐Ÿงต
Threads page
Top-bar Threads button. Pick a thread on the left, click + Add session in the right pane, filter by alias or project.
Path 3
โŒจ๏ธ
CLI
recall threads link <session-id> --thread <id-prefix>. Add --parent to make it a child of a specific node.
Pipe an entire thread back into a fresh Claude conversation
Thread (DAG)5 sessionsCommandrecall context thread:abc | claudeFresh Claude sessioncontext loaded ยท 5 sessionsContinue from wherewe left off and finishmigration phase 2.โ–

Threads

A thread is a DAG of related sessions: an origin, its children, and the work that continued from them. Sessions join by hand, by recall thread sync, or by inference. Operational detail:

#Removal & re-parenting

Right-click a node โ†’ Remove from thread. The session stays in Recall; only the link drops. Children of a removed parent are re-parented to the grandparent (or promoted to origin).

#Cycle protection

Threads are acyclic by construction. The daemon rejects setParent calls that would create a cycle (self-parent, Aโ†”B, longer chains).

#Auto-detection signals

recall threads scan infers parent-child links from:

  • timing proximity
  • file overlap between sessions
  • continuation phrases ("continue from", "based on the plan in...")
  • optional LLM rescore on borderline pairs

recall threads sync captures terminals running in the current repo right now. Idempotent. Manual edges preserved on re-run.

#Codex sessions in a thread

The scanner reads Codex rollouts off the same code path it reads Claude Code transcripts on, so a Codex session joins a thread on the same signals: timing proximity, file overlap, continuation phrases, and the optional rescore. Its user messages and the files its commands touched both count.

One signal abstains, deliberately. The authored-content signal matches a file written in one session against the same text pasted into another, and it reads that from a structured write tool call carrying a file path and a body. Codex has no such tool: it patches through the shell, where the new content is an argument inside a command string with no reliable boundary between the path, the body and the rest of the script. Guessing one would feed false matches into a strong signal, so a Codex session contributes no authored-content evidence at all. It scores on the other signals and is never scored higher than the evidence supports.

The source switch reaches the scan. With recall codex off in force, a scan checks the path against the Codex sessions root before it opens anything, so a rollout is skipped without being opened rather than opened and discarded. Claude Code transcripts are unaffected, and Codex rows already in the database keep the thread edges they have.

Last updated