run a fleet of agents at once + the dashboard

DGC runs a fleet — several agents working at the same time, each with its own conversation. Kick off a long task on one, spawn another, and keep going.

• Ctrl+N — spawn a new agent (even while one is running). The old one keeps working in the background; the new one is a clean slate.
• Ctrl+O — cycle to the next agent. Ctrl+\ — open the dashboard.
• Dashboard — every agent with its live state: ● on screen · ⋮ working · ◆ needs you · ○ idle. Enter attaches · x closes · p pins · r renames. + New agent spawns one; saved sessions are listed to reopen.
• /new DIR — an agent in another folder (below). The dashboard's + Agent in another folder… asks for the folder and does the same.
• When a background agent finishes or needs a decision, the bottom bar shows ⧉ N · ◆ need you — switch to it (Ctrl+O or the dashboard) to answer.

New agents use your current model by default; point one at a different model or a cloud key with /model / /connect for true parallelism. Every agent this terminal opens keeps what the launch was given for the run — an --api-key-env key, and --sandbox with the tools it denies — but not its grants: --allow-tool and --add-dir stay with the launch project. A permission rule or a trusted folder you save in one agent applies to all of them at once.

/new DIR opens an agent in another folder, next to the ones you have, the way the editor opens a chat in another folder. ~, quotes and relative paths work; a relative path starts from the project of the agent on screen. DGC opens the folder's project — it walks up to the nearest .git, DGC.md or .dgc — and the agent works with that project's trust, permission rules, named agents, skills and DGC.md, not the launch project's. Your MCP servers start for it in that folder, and it has its own permission mode, as every agent does. Its chats are saved with that project, so /resume inside it lists them, and so do dgc --continue and the editor opened there. Closing it says how to come back: /new the folder, then /resume.

A folder you have not trusted shows the trust card first — Trust it and open or Cancel — and nothing from it runs until you choose: no agent, no MCP server, no hook, not even git. Trusting it covers everything under it, as at launch; for your home directory, / or a folder that contains your home, Cancel is the row Enter picks. Esc builds nothing and writes nothing.

The first agent in a folder works in the folder itself. Another agent in a checkout an agent of this terminal already works in gets its own dgc/fleet-* worktree, as Ctrl+N does in the launch project; in a non-Git folder it shares the folder, and writes are serialized. Agents of this terminal that share a folder are told about each other, as two windows are.

/new, Ctrl+N and + New agent always mean the project you launched in; /new . is the project of the agent on screen. /new DIR works while a turn runs. A DGC pinned to one project with DGC_PROJECT_ROOT opens no other folder, and a folder inside DGC's own storage (~/.dgc, the fleet and task worktrees) is refused. A path that reads as a command — /new /plan, or a short absolute path the / menu completes to a command — needs quotes or a trailing slash: /new "/plan". The classic terminal (dgc --classic) holds one agent, so there /new DIR tells you to start DGC in that folder instead.

The launch agent stays in the checkout you selected. Every additional agent in a Git project gets an owner-private dgc/fleet-* worktree containing the source checkout's exact tracked and non-ignored untracked baseline. Each checkout has its own crash-safe mutation lease, so fleet writes can proceed concurrently. Closing an untouched managed checkout removes it; changed, committed, uncertain, or still-running work is retained with its visible branch/path. Reopening that saved conversation validates and reattaches to the same checkout. Non-Git projects say when they fall back to serialized shared-checkout writes. /worktree <name> creates a deliberately named long-lived manual branch.

The model's task delegation tool isolates itself automatically in Git projects. Its private checkout starts with the caller's tracked and non-ignored untracked state. DGC applies only a completed child's conflict-free delta; it never overwrites paths that were already dirty, and it retains conflicting or incomplete work with a visible worktree path and branch. Integrated edits remain part of the parent turn's /rewind checkpoint and usage/edit totals.

The three checkout kinds — fleet, named /worktree, and delegated task — are on Worktrees.

Use /tasks to inspect retained work. /tasks apply ID recomputes its delta, rejects paths that were dirty before delegation or changed in the parent, and adds an applied result to /rewind. /tasks drop ID --confirm permanently removes the isolated checkout. Older recovery records created before baseline fingerprints remain visible and droppable but deliberately require manual inspection instead of unsafe auto-apply. VS Code/Cursor exposes the same operations through its command Quick Pick.