Keep the original session running and listed when forking

[snimu]

Fixes ENG-5180.

What this does

/fork no longer kills the session you fork from. The original keeps running — with its subagents, scheduled heartbeats, and warm state — and stays visible in the agents view. You still land in the new forked chat immediately.

What the problem was

Forking used to replace the current session in place: the running session was shut down, its subagents were closed, its scheduled heartbeats were silently handed to the fork, and its identity was taken over. The original survived only as a file on disk and vanished from the session list — "when I do /fork, the original session disappears" (user report).

How it works now

• The daemon gets a new command that copies the chosen part of the conversation into a new session file and stops there — nothing about the running session is touched.
• The client then opens that file as a genuinely new session (its own worker, its own identity) and switches you to it, using the same machinery that already exists for creating and attaching to sessions.
• The fork starts fresh on purpose: no copied kernel state, no copied subagents, no stolen heartbeats. Subagents stay with the original, which keeps running. This also makes forking fast — there is nothing heavy to copy.
• Old daemons that don't know the new command keep the old behavior (the client checks before using it), so nothing breaks across versions.

Changes

• New fork_export daemon command plus the client-side fork flow rewrite (+179/−21 source lines across five files).
• A regression test file covering: both sessions listed after a fork, the original stays promptable, its subagents stay open, its heartbeats stay put, the fork starts with no subagents — plus connection-level and protocol-compatibility tests (+703/−1 test lines).
• Changelog entry and a small accuracy fix in the extensions doc.

Checks

• npm run check clean; 138 targeted tests pass (108 re-run after merging the newest main).
• Review went through two rounds; the first caught three real issues (double hook emission, a concurrency race between simultaneous forks, unsafe cleanup on failure) that the final version fixes.
• Validated end-to-end in a real terminal with a fresh daemon (31 recorded steps): fork with a live subagent → both sessions listed, original responds afterwards with its subagent intact, fork starts empty, killing the fork leaves the original untouched. Two separate daemon workers confirmed in the logs.

Known cosmetic quirk (pre-existing display behavior, left for a follow-up)

Right after forking, the agents view may briefly group the fork under the original (it is linked as the fork's parent) until the fork's own summary appears; a killed fork also shows as a completed child row when expanding the original. The underlying state is always correct.

---

Note

Medium Risk
Changes session identity and daemon fork orchestration (create, reattach, kill on failure) with backward compatibility via capability checks; incorrect cleanup or races could strand workers or lose attachment, though tests cover serialization and failure paths.

Overview
Daemon /fork no longer tears down the source session. When the daemon supports fork_export, the client exports the chosen branch to a new session file, spawns a new worker on that file, and reattaches you to the fork while the original session keeps running in the list with its subagents, heartbeats, and leases intact.

Runtime and protocol: AgentSessionRuntime adds exportForkBranch (shared resolveForkTarget) to write a branched JSONL file without finishSessionReplacement. The daemon exposes fork_export (schema revision 17) and routes it to the source worker without rebinding cron jobs; legacy fork still replaces in place for older daemons, non-persisted sessions, or in-process mode.

Client orchestration: DaemonAgentConnection.fork serializes forks and session switches via withSessionTransition, handles create/reattach failures (orphan file cleanup, kill fork worker, optional reattach to source), and documents extension lifecycle differences in extensions.md.

^{Reviewed by Cursor Bugbot for commit 93f9493. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep the original session running when forking in daemon mode

• Adds exportForkBranch to AgentSessionRuntime that writes a forked session to a new file without replacing the current runtime, leaving the original session active.
• Adds a fork_export daemon command (protocol revision 17) that invokes exportForkBranch on the source worker and returns the new session file path.
• DaemonAgentConnection.fork now uses fork_export when the daemon advertises the capability: it creates a new worker on the exported file and switches the client to it, while the original session and its subagents/leases continue running.
• Falls back to the legacy destructive fork when the daemon lacks the capability or the session is not persisted (in-memory).
• Risk: reattach failures after a successful session switch can leave the client attached to the fork with no recovery path if the fallback reattach to the source also fails.

^{Macroscope summarized 93f9493.}

[macroscopeapp]

🟠 High agent-connection/daemon-agent-connection.ts:1240

A fork fails after reconnecting to an older daemon instead of falling back to legacyFork. The capability check occurs before requestData, but a recovered request can later throw DaemonCapabilityUnavailableError; catch that post-reconnect error and invoke legacyFork(entryId, options).

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @packages/coding-agent/src/modes/agent-connection/daemon-agent-connection.ts around line 1240:

A fork fails after reconnecting to an older daemon instead of falling back to `legacyFork`. The capability check occurs before `requestData`, but a recovered request can later throw `DaemonCapabilityUnavailableError`; catch that post-reconnect error and invoke `legacyFork(entryId, options)`.

Evidence trail:
packages/coding-agent/src/modes/agent-connection/daemon-agent-connection.ts:245-248, 1232-1249, 1301-1311, 1519-1533 at REVIEWED_COMMIT; packages/coding-agent/src/modes/daemon/daemon-client.ts:72-84, 282-285, 293-318, 431-460 at REVIEWED_COMMIT; git diff MERGE_BASE REVIEWED_COMMIT -- packages/coding-agent/src/modes/agent-connection/daemon-agent-connection.ts

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 93f9493. Configure here.}

[cursor]

Legacy naming left in fork path

Low Severity

The in-place fallback is named legacyFork, and related protocol comments and test titles also use “legacy” vocabulary. Project review rules disallow migration-era terms like legacy in names, comments, and test titles even when an older protocol path remains for compatibility.

Additional Locations (2)

• packages/coding-agent/src/modes/daemon/daemon-protocol.ts#L104-L107
• packages/coding-agent/test/agent-connection-daemon.test.ts#L1115-L1124

 

^{Triggered by project rule: Review rules}

^{Reviewed by Cursor Bugbot for commit 93f9493. Configure here.}