Workspace forks

Workspace forks let Roder branch a conversation or task into an isolated writable workspace. A fork is a Roder runtime concept: it can be backed by a Git worktree, a Rift copy-on-write snapshot, or a remote-runner session, but it is not a GitHub fork and not an inference provider.

Providers

• git-worktree creates roder/fork/<name> worktrees under the source repository.
• rift shells out to a configured Rift binary for copy-on-write snapshots.
• remote-runner can attach a fork to a fresh remote-runner session when a host constructs that provider.

Providers fail closed on unsafe inputs: dirty source workspaces are rejected by default, removal requires the caller to repeat the exact fork workspace path, and fork metadata never carries secrets.

Conversation forks

Forking a thread creates a child thread with the parent transcript history and a fresh workspace fork. Tool calls are not replayed. The child keepsparentThreadId, forkedFromTurnId, andworkspaceFork metadata in both JSONL and PostgreSQL stores.

/fork spike-ui
/fork status
/fork remove /absolute/path/to/fork

roder thread fork <thread-id> --name spike-ui
roder forks providers
roder forks list --source /path/to/repo
roder forks create --name experiment --provider git-worktree

Protocol

App-server clients use thread/fork, thread/fork_status,thread/remove_fork, forks/providers/list,forks/list, forks/create, and forks/remove. Fork lifecycle events are emitted as normal runtime events, so TUI, desktop, and automation clients can render the same state.