resume, jump, and undo whole turns

Every conversation is a session, saved as you go.

• /resume — reopen a past session (newest first); dN deletes one.
• /new (Ctrl+N) — start fresh; DGC auto-titles it from your first prompt.
• /new DIR — in the terminal, an agent in another folder beside this one, with that folder's trust, rules and saved chats (see Multiple agents). /resume in that agent lists the folder's chats.
• /name — rename the current session, while a turn is running too.
• /branch (/fork) — continue in a new chat from here. Everything so far comes with you — the conversation, the standing goal, the todos, the recovery points — and the chat you branched from keeps exactly what it had, so a second approach costs you nothing. /branch <name> names it; otherwise it takes the parent's name with (branch) after it. The editor offers the same thing under a finished answer.
• /history (Ctrl+R) — search and recall any past prompt.
• /jump — scroll the transcript straight to a past turn.
• /recall — read the earlier conversation a compaction summarised away (see below).
• /export (dgc export [ID] [FILE]) — save a session as Markdown, archived turns included. Nothing the full-screen app shows survives in your terminal's scrollback; this does, and so does dgc --classic, the inline mode.
• dgc export-training / /export-training — export your sessions as scrubbed fine-tuning JSONL (see Training export); read-only, never modifies a session. The slash command runs the same export for the current project; the VS Code palette exposes it as DGC: Export Training Data.
• /handoff — create a bounded, redacted continuation document from one stable session generation. DGC saves it as a new private HANDOFF-*.md through the workspace lease; an overlapping turn is rejected instead of mixed into the file. The Handoff page covers the editor command, headless save, and what the file holds.

When a session grows past compact_threshold of the context window, DGC replaces the older turns with a summary. That is the model's limit, not yours: the turns themselves are kept beside the session, so scrolling up shows Your earlier conversation is still here instead of a bare summary. Click it, or run /recall, to read those turns back in place; click again to hide them. /recall also works in /copy select mode, where the header is not clickable.

What is kept is a display copy — the text of your prompts and the model's replies, plus which tools each turn used. It carries no tool results and nothing that could be fed back to a model, and showing it never changes what the model sees or what the turn costs. Secrets are removed with the same redaction that protects the saved session, including retroactively: a credential DGC learns about later is scrubbed from turns archived earlier.

The archive is bounded (recall_max_bytes, 512 KB by default) and drops the oldest turns first when it is full, saying so on the same line. Deleting a session deletes it too.

• /rewind — restore both the code and the conversation to how they were at a chosen turn. What a recovery point holds, what it cannot take back, and the editor's Undo are in Checkpoints & rewind.

The + beside the model name opens another chat in the same folder, and Open a chat in another folder (also DGC: Open a Chat in Another Folder…) opens one in a different project. Every chat has its own model context, session file, turn and permission mode — not a second view of the same conversation — so the chat you switch away from keeps working. A chat in another folder also brings that folder's project settings, trust, MCP servers, skills and permission rules with it. A rail appears above the transcript with one tab per chat, naming the folder when it is not the window's; a pulsing dot means that chat is mid-turn, a square amber dot means it is waiting on a decision only you can make, and a number is how much it has said since you last looked. Click a tab to switch, the × to close one. DGC: Open a Second Chat and DGC: Switch Chat do the same from the command palette.

All of them run in one dgc serve, the way Codex runs its threads: one process, each chat in its own folder. Each still starts the MCP servers its own folder configures. What one chat does stays in that chat — a Stop ends only its own turn and its own approval cards, and a slow command in one (a compaction, a rewind, reconnecting MCP servers) never holds another chat's Stop or approvals. What is yours rather than a chat's — a permission rule, a trusted folder, an MCP server you add or remove — reaches every open chat at once. dgc.shareBackend turns the sharing off and gives each chat a process of its own. The extension needs DGC CLI 0.47.0 or newer.

While a chat's turn runs you can still:

• switch to another chat, or open a new one — the turn carries on;
• rename it (DGC: Name Session, or /name);
• open a saved session — it opens in a chat of its own beside the running one, instead of replacing the conversation that turn belongs to;
• install or remove a plugin — its tools and skills reach the running turn at its next request.

There is no built-in ceiling — open as many as your machine and your model budget allow. What another chat really costs is another model context — tokens on a cloud endpoint, or a share of a local model — and only you can judge that. Writes from several chats into one checkout are serialised by the workspace write lease; chats in different checkouts write at the same time. If you want DGC to stop you at a ceiling, set dgc.maxLiveChats in the editor's settings; 1 keeps it single-chat.

A second chat is for parking long work — a migration, a long test run — while you carry on. Delegation (Sub-agents) is still the right tool for fanning out one task across workers.

Switching does not replay anything the panel kept: the chat you arrive at is rebuilt from the backend's snapshot of that chat, taken under its turn lock and followed by a fresh announcement of whatever approval or question it is blocked on. So a chat you left mid-turn comes back exactly where it is now, not where it was when you left it.

Closing the window stops every chat in it. Closing one chat stops only that chat; the backend keeps running for the others, and the last one to close stops it. If a background chat's backend dies while you are not watching, its tab says so and switching to it starts a new one on the same session rather than an empty chat.

Two chats, two windows, or a window and a terminal are all two agents editing the same files. They know about each other. Each leaves a note in ~/.dgc/peers/, refreshed while it runs, and every agent reads the others: you get one line when that changes — "1 other DGC is working in this folder." — and the model is told the same thing, with the instruction that matters: do not revert or "fix" a change you did not make, and if their work conflicts with yours, stop and say so rather than choosing for you.

Two worktrees of one repository count as the same place, because they share branches and history.

A note is only trusted when the process behind it can be proved to be the one that wrote it — process ids get reused, and a stale note whose id now belongs to something else must not read as a live DGC. Where that cannot be proved, DGC says the agent may still be running rather than claiming either way. A DGC that exits cleanly removes its note; one that crashes leaves it, and it expires.

Rewinding is DGC undoing DGC. If a file has changed since DGC last wrote it — another window, another tool, or you in your editor — the rewind stops and names the files, and nothing is restored. It is all-or-nothing on purpose: a partial rewind would leave the folder in a state neither you nor DGC chose.

A rewind of DGC's own work is unaffected, and so is one where DGC has no record of what it left: the guard fires on evidence that a file was changed, never on uncertainty.

A delegated task runs in its own disposable worktree, so edits there need no snapshot. A write outside it — a file in your project, a script in /tmp — is an ordinary change to your files and is captured by the parent chat, which is what can undo it. Until this release those writes were refused outright: "DGC could not capture its pre-edit state first".

Every DGC on a machine reads and writes the same ~/.dgc/config.json, so two editor windows are two processes sharing it. A save writes only what that DGC actually changed, merged into whatever is on disk at the moment it writes, under a lock: a model chosen in one window and a thinking level chosen in the other both survive, and the one that saves second adopts the other's change rather than reverting it.

Permission rules merge the same way, rule by rule. This matters most in the direction that protects you: a deny added in one window used to be erased by an unrelated settings change in another, because a save rewrote the whole file from one process's memory. A rule you revoke is still revoked — the merge carries removals, not only additions. Rules a workspace brings (<project>/.dgc/permissions.json) stay live-only and are never written into your own config, and they stay in force for the whole session, whatever else is saved. Trusted folders merge folder by folder, so a folder you revoke in one window is not trusted again by another's save.

What a running conversation is using is never changed underneath it. Its permission mode, its model and endpoint with their key, and its sampling settings stay as they are when another window or chat changes them; the change is saved, and it is what the next session starts with. Keys in ~/.dgc/secrets.json merge the same way as the settings, so switching endpoint and key in one window no longer has the new key wiped by the other window's next save.

A session is held by whichever DGC is running a turn in it, so a second window — or the second chat in this panel — opening the same session is told it has an active turn in another DGC process. That protects the transcript: two backends writing one session would interleave their turns.

The lease is released when that turn ends, when its DGC exits, and if its DGC crashes — it is an operating-system lock, not a file DGC has to remember to clean up.

It is also released when the editor that owned the backend goes away. An editor says it is still there about once a minute; a backend that was hearing that and stops hearing it treats the window as closed and lets the session go, within about fifteen minutes. That wait exists because a backend cannot otherwise tell a closed window from a user who is thinking: its input stays open for as long as the editor process lives, and an editor can leave that process behind when it reloads. Nothing is dropped to make this happen — a backend with a turn running, a background monitor armed, a detached sub-agent still working, or an open goal stays up regardless, however long it has been quiet.

Handing the session to a window that is asking for it is a faster, stricter question, and it is answered by the chat panel rather than by the editor process. The panel itself says it is on screen every twenty seconds. A window that reloaded takes its panel with it, so those statements stop at once -- even in the case that started all of this, an editor host that outlives its own window and goes on insisting, on a timer, that everything is fine. After about two minutes with no word from any panel, the window that asked gets the session. Closing the chat view without closing the window is the one case where a live window has no panel to speak for it: the editor says so, that buys a bounded extra minute, and then the session goes to whoever is waiting.

If you would rather not wait, start a new session, or close the other window.