Agent backends: the CLI that runs each agent

What a backend does

A model on its own only produces text. To change code it needs a harness: something that sends prompts, executes the tool calls the model asks for, such as reading files or running commands, and feeds the results back. Coding CLIs fill that role, and DevFlow treats them as interchangeable backends.

The two in DevFlow

OpenCode is the default. It is multi-provider, so it can reach Anthropic, OpenAI, Google and OpenRouter with the keys a workspace stores.

Claude Code is supported but disabled unless the operator sets CLAUDE_BACKEND_ENABLED. While it is off, any selection pointing at Claude Code is moved to OpenCode with the workspace's OpenCode model filled in, and the UI hides the Claude Code choice.

One process per run

For each agent run, DevFlow starts the CLI as a subprocess in the task's worktree. Its environment is built from an allowlist, so server secrets never reach it.

On the Landlock path, the subprocess is confined to the worktree and a few working directories. In container mode, OpenCode runs inside a per-run container on an internal network instead.

Keeping tool rules equal

Roles have different tool rights: the implementer may edit, the summarizer may only read. Before each OpenCode run, DevFlow writes an agent file for the role, inside the worktree, with the compiled instructions and an explicit allow and deny matrix.

That file keeps the same per-role whitelist on both backends, and it also gates tools from MCP servers per role.

One OpenCode tool is denied for every role: task, which would let an agent spawn its own subagents. DevFlow orchestrates the pipeline itself, and subagents would be invisible to its scheduler, cost accounting and sandbox.

Choosing per role

A backend is chosen together with a model at every routing level: task override, workspace override, tier and workspace default.