Skip to main content
Once a conversation ends there are three things you can still do with it: replay it (watch the process again), publish it (produce a link anyone can open), and fork it (branch a new conversation from some point in the middle). Each has a clear boundary, and each has things it cannot do.

​
Replay

The replay page lives at /replay/{session id}. It is not “reopen the chat window” — it is a read-only player: messages appear one at a time in order, long assistant responses stream character by character, and a control bar lets you pause, seek, and change speed.
Every write action on the replay page is a no-op — sending, editing, and regenerating are all unavailable here. That is deliberate: replay is for watching. To continue the work, return to the original conversation or fork one.

​
What is restored

​
What is not restored

The sandbox is live; a replay is not. Sandboxes are reclaimed after 15 minutes idle (SANDBOX_IDLE_TIMEOUT_MINUTES=15, with the E2B-side timeout also at 900 seconds), so:
  • Website preview links are dead — the recorded preview URL points at a dev server that no longer exists
  • Files that only ever lived in the sandbox cannot be opened — those show “This file is stored in the sandbox and cannot be accessed in replay mode”
Files already uploaded to the cloud are unaffected — anything in a delivery card with a link stays downloadable. Widget HTML over 256KB is likewise persisted to object storage and renders normally on replay.
Also not restored: the plan-mode .plan.md file, memory graph state, and the message version switcher.

​
Publishing

Every session has an is_public flag, and it is the only visibility gate: Anyone else opening an unpublished session gets “This replay is not public.”
Sharing is all or nothing: no password, no expiry, no “share only the first N messages.” Once public, the entire conversation — every message you sent, every tool the expert called, every intermediate artifact — is visible to anyone with the link. Review the content before publishing.
Strong public replays can be curated by the platform into the featured slots on an expert page or the home page. Featuring requires the corresponding expert to be published (or to be an official platform expert).
Known limitations: replay view counts are not actually tracked (recordView only touches the timestamp; there is no counter column). The same applies to the session’s published_resource_ids field — the resource listing endpoint always returns an empty array. Do not treat either as a working feature.

​
Fork: a brand-new conversation

Forking cuts at a chosen message and copies that message and everything before it into an entirely new session.

​
What is copied, what is not

A fork is a real copy, not a diff. Messages are inserted into the new session with fresh IDs, and the two are fully independent from then on. Forking a long conversation genuinely produces a duplicate — do not treat it as free.More importantly: the sandbox does not come along. Files the expert wrote, services it started, dependencies it installed — none of that exists in the forked session. A fork inherits the conversation context, not the working environment. If the artifacts you care about live in the sandbox, have the expert deliver them to the cloud first, then fork.
A forked conversation shows a dashed divider at the top with a “Forked from conversation” link back to the source.

​
Failures and what to do

​
Fork vs edit/regenerate — two different things

An easily confused pair: Edit and regenerate use the message branching mechanism: each user message is a “turn,” editing creates a sibling turn, and the session records which branch is currently displayed. Switching versions jumps to the newest continuation under that branch, matching mainstream chat behavior.
Sessions created before the branching migration have no branching support, and editing in them is destructive — it deletes everything after that message. The absence of a version switcher in the UI is how you tell which kind of session you are in.

​
Typical uses

Comparing approaches: once the expert has finished one implementation, fork from the “start implementing” message and try a different stack in the new session, then compare the two side by side. Isolating risk: before an operation you are unsure about, fork and try it there. Remember the new session has no sandbox state — you are testing the decision path, not the same files. Teaching and review: publish a conversation where the expert solved something hard and send the link to a colleague. They see the whole process, dead ends included, which is often more useful than the conclusion. Tracing a problem: replay when a result is wrong, expand the tool call cards, and read parameters and returns one by one until you find where it diverged.

​
Keep reading

Sessions and workspace

How sessions, workspaces, and sandboxes relate

Workspace panels

The preview, files, and widget panels

Files and cloud drive

Getting sandbox artifacts delivered to the cloud

Content plaza

The other publishing path: promo notes