Resume & restart

Closing Birch — or restarting your computer — doesn’t end your workspaces. The worktree, branch, agent kind, and launch command are all persisted; a Claude Code, Codex, or OpenCode session is rediscovered from its CLI’s store and resumed the first time you re-enter the workspace in a new app run. This page explains exactly what persists, what resumes, and what starts fresh. See AI in Birch for how sessions fit the bigger picture.

What persists — and what doesn’t

	Persisted?	Notes
Worktree + branch	Yes	On disk; worktrees are kept even after the shell exits
Agent kind	Yes	Which agent the workspace belongs to
Exact launch command	Yes	Including --model / --effort / --settings flags
Creation prompt	Yes, for display only	Shown in the properties panel’s PROMPT section; never typed again
Session id	No	Rediscovered live from the agent CLI’s own session store

How resume works

The first time you open a workspace in a given app run, Birch locates the newest session the agent CLI itself recorded for that worktree and relaunches the recorded command with the right resume argument:

Agent	Session store consulted	Resume command
Claude	~/.claude/projects/ transcripts	claude … --resume <id>
Codex	~/.codex/sessions/ rollouts	codex resume <id>
OpenCode	OpenCode’s own data folder (~/.local/share/opencode/)	opencode … --session <id>
Custom	The store of the CLI named by the command’s first word, if that is claude, codex, or opencode	The matching resume argument — otherwise relaunched unchanged

OpenCode: Birch 0.38 and later

OpenCode sessions resume after a restart from Birch 0.38 on; earlier versions opened a new OpenCode session instead. Birch picks the newest top-level, non-archived OpenCode session that ran in that workspace’s folder — never a sub-agent’s session, and never one from a sibling workspace of the same repository. It reads both of OpenCode’s session stores (the older JSON files and the newer opencode.db) and takes the newer match.

A Custom command isn’t opaque to resume: Birch looks at its first word, and a custom command that runs claude, codex, or opencode gets that CLI’s matching resume argument. Only genuinely unrecognized commands are relaunched exactly as recorded — Birch never guesses a resume flag that could error out and leave you with a bare shell. Workspaces created before Birch recorded agent kinds have every locator probed, with the newest session winning, so they resume too.

The first-entry rule

A resume happens once per app run, on the workspace’s first launch. If you quit the agent and re-select the workspace later in the same run, it starts fresh — the same behavior as before restarts were survivable. To get back into a past session later in the same run, ask the agent CLI itself: run claude --resume or codex resume in the workspace terminal and pick the session (in OpenCode, use its /sessions command). The next app run resumes the newest session again on first entry.

A resume brings back the conversation, not a turn that was still running when Birch or the computer went down: the agent opens at its prompt with the history in place, so just ask it to continue.

When there’s nothing to resume

If no session is found — a brand-new worktree, a cleaned agent store — the recorded command simply runs without a resume argument: a fresh agent in the same worktree, with all the workspace’s files and commits intact.

Picking up a CLI session in Birch

Started an agent in a plain terminal? The birch-status plugin ships a /birch slash command that runs birch open with the current session id and working directory, handing that exact session over to a Birch workspace.

Quitting while agents run

Closing Birch with live agents raises an “Agents are still running” confirmation that counts how many are working and how many are waiting for your input, and warns that quitting stops them mid-task, so their current turn may be lost — workspaces and files are kept. Cancel keeps them running; Quit anyway (Close anyway on Windows) quits.

Cleaning up

Worktrees are never deleted implicitly — exiting the agent keeps the workspace in the sidebar. To remove one:

• Sidebar — right-click the workspace row → Delete workspace… (or its trash button). Birch deletes the worktree and its local branch; the remote branch and any pull request stay as they are. See What deleting loses below.
• CLI — birch worktree rm <name> removes the worktree; branch deletion is opt-in via --delete-branch. See birch worktree.

Danger

Deleting a workspace discards any uncommitted work in its worktree, and the GUI delete also removes the workspace branch. Push or merge anything you want to keep first.

What deleting loses

The Delete this workspace? dialog opens at once and names the workspace, its agent, and its branch. While you read it, Birch checks for unsaved work (Checking for unsaved work…) and then lists exactly what the delete would cost:

• uncommitted changes — how many files, and how many of them are new files that will be deleted;
• commits that haven’t been pushed, or a branch that was never pushed and isn’t in the default branch;
• an agent that is working or waiting for your input (deleting stops it), or open terminals that will be closed;
• the branch’s pull request — it stays open, or it is already merged;
• for a cloud workspace, that the claude.ai session is not deleted.

Only when the check proves it does the dialog say “Nothing will be lost: no uncommitted changes, and every commit is pushed or merged.” If the check can’t run, it warns that any uncommitted changes or unpushed commits will be lost. The red Delete workspace button is never triggered by Enter — click it; Cancel or Esc backs out. If the delete fails, an error dialog says why.