dsh-autofork

A single DSH turn can take ten-plus minutes. While the agent is working, you are usually stuck in queue or waiting for a steer step boundary, so your day fragments into wait time. Opening several sessions and toggling between them helps, but human working memory struggles to track three or five live conversations, and context switching breaks flow. dsh-autofork changes this must-wait interaction model: when the agent is busy, speaking immediately opens a new session for you, while the original session keeps running in the background, never aborting, and re-injects its result into the session you are now using.

Its core ability is passive forking, not asking the agent to decide whether to parallelize. You do not need to judge whether to spawn a subtask, how many sessions to maintain, or which one is waiting; you simply say what you mean when you mean it. Forked sessions are grouped with consistent marks, and the new fork tab shows the family tree, live state, triggering instruction, and timing. The foreground agent can also use fork_list, fork_steer, and fork_cancel to inspect or steer family sessions, while background re-injections and in-flight digests collapse into single-line summaries.

It fits people who frequently run long tool chains, long generations, or multi-step debugging in DSH and want to interject, add requirements, or change direction without switching between windows. It does not remove causal dependence in the work itself: if the next instruction depends on the current result, you still need to wait for that result. Forked sessions also share the same working directory, and bash operations such as git commits or file redirections are not protected by write guards, so concurrent file changes must be coordinated manually.