Skip to main content
Archductor gives every task its own Git worktree, branch, and running environment, so several coding agents can work on the same codebase at once without trampling each other. Use it when one repository has several streams of work in flight: create a workspace, start Codex or Claude Code, review the diff, open or merge a pull request, archive the workspace, and start the next one — without leaving the app.

Your first workspace

Install to merged pull request.

Running work in parallel

Ports, copied files, conflicts, layouts, shortcuts.

Agent sessions

Queueing vs steering, plan mode, background tasks, MCP.

Running on a server

Headless daemon, SSH transport, remote import.

​
How it is built

Three cooperating pieces, and the split matters when you are debugging:
  • archcar — a Rust daemon that owns everything durable: SQLite state, managed agent sessions, chat threads, input queues, and PTY-backed processes.
  • The desktop app — Electron and Solid.js. It holds no in-process state and talks to the daemon over its socket.
  • The archductor CLI — the same backend, exposed for automation and scripting.
Because the daemon owns the state, the app and the CLI are peers rather than a primary and a fallback, and the daemon can run on a different machine entirely.
Inspired by Conductor, and its own product: a Linux-first desktop app with committed, file-editable defaults instead of settings you click through. Linux is the primary manually validated release target. macOS and Windows are compile and smoke targets; native Windows stays a preview until its manual package checklist passes.

​
Product structure

These terms are used consistently across the app, the CLI, and these docs. They nest. The rule that follows from it:
  • Projects own repository-level configuration.
  • Workspaces are the task and review unit.
  • Sessions, terminals, scripts, and agents live inside a workspace. Several chats in one workspace is normal; it does not mean several workspaces.

​
What works today

  • Add a project from a local path or a clone URL.
  • Create workspaces from a branch, a prompt, a GitHub issue, a GitHub pull request, or a Linear issue.
  • Per-workspace Git worktree, branch, .context directory, and a reserved ARCHDUCTOR_PORT block; many workspaces per repository in parallel.
  • Shell, Codex, Claude Code, and Gemini CLI sessions with persistent transcripts and durable, daemon-owned input queues.
  • Review surfaces in one place: changed files, diffs, todos, local comments, sibling-workspace conflicts, PR checks, PR comments — any of which can be staged back into the agent’s queue.
  • Create, refresh, merge, and archive GitHub pull requests through your local gh authentication, with configurable merge blockers.
  • Fork any message into a new chat or a new workspace, carrying the conversation with it.
  • Modular layouts with four immutable built-ins, synced custom presets, and a per-project default.
  • Run the daemon on a server and drive it from any machine over SSH; copy a workspace and its chat back to your laptop.
  • File-editable repository settings, committed with the code.
  • An MCP server, so agents can read and drive Archductor itself.

​
What is still rough

  • The terminal handles common ANSI and control redraws but is not a full emulator.
  • PR review-thread resolve and reopen are CLI-only.
  • Some settings keys are accepted by the schema but not yet acted on — the settings reference says which.
  • Native Windows compiles and packages, but its runtime checklist has not passed.
  • Flatpak packaging is experimental.

​
What it does not own

Archductor is not the memory layer — that is Archivum. It is not the behavior verification layer — that is Archfleet. Archductor owns the workspace lifecycle and everything between “start this task” and “the pull request is merged.”