Most agent tools make that decision for you, permanently, the day you install them. The CLI is baked into the product — so switching which AI you're working with doesn't mean changing a setting, it means changing tools, throwing out however you'd already set things up, and starting over somewhere else.
DF Code doesn't work that way, because nothing about how it spawns an agent assumes which CLI is on the other end. Every run — whether it's a live chat or a Conductor deciding what happens next in the background — goes through the same Connector abstraction, a base class that owns the shape of the conversation without knowing or caring which tool is actually answering. Four connectors are registered today: Claude, Codex, Gemini, and Aider.
That abstraction is what makes the choice a setting instead of a commitment. One connector is the install-wide default. Any workspace can override it just for itself — the same shape DF Code already uses for how often an agent checks in, or how long it's given before it's considered stuck. Nothing else about that workspace has to change to make the switch; the override is the whole story.
Which means a single project doesn't have to pick one AI and live with it everywhere. Give a Reviewer workspace a different connector than its Engineer, and each keeps doing its own job on whichever tool actually suits it — without touching the pipeline that connects them.
Worth saying plainly, because a belief in possibility is only useful when it's honest: Claude is the one connector actually proven against a real CLI today, including the session hooks that keep a terminal and a workspace in sync. Codex, Gemini, and Aider are registered and ready to build on — best-effort scaffolding against each tool's own documented non-interactive mode, not yet run end-to-end the way Claude has been. Gemini and Aider in particular don't have a structured event stream to parse yet, so what comes back leans on a plain-text fallback instead of the richer, tool-call-aware view Claude gets. The door's open. Walking all the way through it for every tool is still ahead.
The part worth sitting with is what that openness actually costs to extend. Adding a new CLI to DF Code is: subclass the Connector base, teach it how to build that tool's arguments and read its output, and register it. Nothing about the chat route or the Conductor's own spawner has to change to make room for it. That's not a hypothetical nicety — it's the actual reason a fifth connector, or a tenth, stays a small piece of work instead of a rewrite.
Q: Does DF Code lock you into using Claude specifically? A: No — connector selection is a global default set in Settings, with an optional per-workspace override, resolved as workspace.connectorId || settings.connectorId || 'claude'.
Q: Can different workspaces in the same install run different AI CLIs? A: Yes — a workspace's own connectorId overrides the install-wide default just for that workspace, so one project can run Codex while another stays on Claude.
Q: How do you add a new AI CLI to DF Code? A: Subclass the Connector base class, implement its run/decision-run/title-generation argument builders and its event parser, and register it in server/connectors/index.js — no changes to the routes that spawn it.
Q: Are all of DF Code's registered connectors equally ready to use? A: No — only Claude is verified against a real CLI today. Codex, Gemini, and Aider are best-effort scaffolding, and Gemini and Aider specifically lack a structured output stream, so their results rely on a plain-text fallback.