Claude Code Agent Farm: Running 20+ Coding Agents in tmux Panes

The problem is coordination, not model access

Running one Claude Code session on a codebase is a solved workflow. Running twenty of them at the same time on the same repository is not, because the agents do not know about each other. Two sessions can edit the same file, one can revert another's work through git, and neither reports a conflict. The repository describes its purpose as orchestrating multiple Claude Code agents "working in parallel to improve your codebase through automated bug fixing or systematic best practices implementation."

The intended user is someone with a repository large enough that sequential agent runs are the bottleneck, and with enough tooling discipline to trust unattended edits. The README lists 34 technology stacks, from Next.js and Python through Rust, Go, Java, Angular, Flutter and C++. That breadth suggests the authors expect the framework to be pointed at whatever stack a team already has rather than at a specific niche.

How the agents are actually driven

There is no SDK integration here. According to the README, the orchestrator "doesn't hardcode the `claude` binary, it simply types `cc` into each tmux pane." That single design decision explains most of the framework's behaviour and most of its limits. Each agent is a tmux pane running an interactive CLI, and the orchestrator's job is to launch panes, watch their terminal output, and react.

Coordination between agents is handled by a lock-based system that the README describes as preventing conflicts between parallel agents. Beyond that description, the material does not specify the lock granularity, where locks are stored, or what happens when an agent holds one and dies. That is a gap worth checking in the source before trusting the framework on a repository where two work items touch the same module.

Monitoring is similarly terminal-oriented. The README lists a real-time dashboard with context warnings, heartbeat tracking and tmux pane titles. Context management works by having agents clear their own context when nearing limits, plus a broadcast of `/clear` to all agents on Ctrl+R. Auto-recovery restarts agents with an idle timeout that adapts to observed work patterns. Every one of those mechanisms depends on parsing what the CLI prints into the pane.

The cc alias is the contract

The setup script configures a shell alias, and the README gives the exact form:

alias cc="ENABLE_BACKGROUND_TASKS=1 claude --dangerously-skip-permissions"

That flag combination is the load-bearing part. Unattended agents cannot answer permission prompts, so the framework runs them with permission checks disabled. The README also notes the setup script detects and fixes common mis-quotings and patches incorrect quote patterns in existing aliases, which tells you the alias is fragile enough in practice to need repair logic.

Because the orchestrator only types `cc`, the alias can point elsewhere. The README shows OpenCode and Codex CLI examples using npx invocations, and warns that monitoring is Claude Code specific. Readiness detection depends on the "Welcome to Claude Code!" banner, context percentage parsing assumes Claude Code output, `/clear` resets assume the same, and the `~/.claude/settings.json` backup and corruption checks are Claude-specific. With another CLI the README says agents will launch and work on your prompt, but auto-restart, context management and health checks will be degraded or inert. The `doctor` command will also flag a non-standard alias as incorrect, which the README calls expected and harmless.

Getting it running: setup, doctor, configs

The documented path starts with cloning and running the setup script:

git clone https://github.com/Dicklesworthstone/claude_code_agent_farm.git cd claude_code_agent_farm chmod +x setup.sh ./setup.sh

That script checks and installs prerequisites, creates a Python 3.13 virtual environment, installs dependencies, configures the `cc` alias, sets up direnv, and handles bash and zsh. Prerequisites listed are Python 3.13+ managed by `uv`, tmux, the `claude` command, git, your project's own tools, and optionally direnv.

Verification is a separate step:

claude-code-agent-farm doctor --path /path/to/project

The README says this checks Python version compatibility, tmux, git and uv availability, Claude Code configuration and API keys, project-specific tool availability, and file permissions. A run then takes a path and a config file:

claude-code-agent-farm --path /path/to/project --config configs/python_config.json

For the best practices workflow, the README instructs copying a guide into the project first, for example `cp best_practices_guides/NEXTJS15_BEST_PRACTICES.md /path/to/project/best_practices_guides/`, then running with `configs/nextjs_best_practices_config.json`. Configs are JSON with variable substitution and dynamic chunk sizing, and `max_agents` is the key that caps concurrency, with the README citing 20+ agents by default and up to 50. Shell completion is installed with `claude-code-agent-farm install-completion`, optionally with `--shell bash`, `zsh` or `fish`.

Where the design runs into trouble

The permission flag is the first real limitation, and it is not a bug. `--dangerously-skip-permissions` means every agent edits files without asking. On a repository with a clean git history and small, independent work items, that is manageable. On a repository where an agent can touch migrations, infrastructure definitions or dependency manifests, a bad edit propagates before anyone reads it. The README's own safety features (settings backup and restore with size-based rotation, file locking, atomic operations) protect the orchestrator's own state, not your source tree.

Non-Claude CLIs are the second limitation, and the README is unusually direct about it. The framework will launch them, but the feedback loop that makes auto-recovery and context management work is gone. You get parallel panes and nothing watching them.

The third issue is startup cost. The README warns that npx startup latency multiplies, because every agent pane pays the resolution cost at launch, and recommends a one-time global install instead. It also recommends pinning an exact version rather than `@latest`, since a version change mid-run is not something the framework can absorb.

Finally, the licence. The README badge says MIT with an OpenAI/Anthropic rider, while the repository metadata reports NOASSERTION. Those two do not agree, and the rider is not described in the material available here. Read the LICENSE file before shipping anything built on this.

Compared with Anthropic's own subagent model

Claude Code ships its own way to parallelise work through subagents, and the difference in approach is structural. Subagents run inside one Claude Code process and one context budget. They report back to the parent session, which owns the merge. There is no tmux, no shell alias, and no terminal parsing, because the parent process already knows what its children are doing.

Agent Farm takes the opposite route. Each agent is an independent interactive CLI in its own pane, with no shared parent. Coordination has to be reconstructed from the outside using locks, pane output parsing and git commits. The README lists progress tracking through git commits with diff summaries and HTML run reports, which is the mechanism that makes independent sessions legible after the fact.

The trade-off is legibility against isolation. Subagents share a context window, so a large sweep competes for one budget. Agent Farm gives each pane its own budget and its own restart lifecycle, which is what makes 20 to 50 agents conceivable. The cost is that everything the parent process would know for free has to be inferred from a terminal.

Maintenance surface and what to check first

The framework has more moving parts than its README implies. There is a Python package, a shell setup script, a modular tool installation system with 24 scripts run through `tool_setup_scripts/setup.sh`, per-stack JSON configs, shell completion for three shells, and an alias that the setup script actively repairs. Each of those is a place where a change to Claude Code's terminal output can break monitoring without breaking agent launches, which is the worst kind of failure because it looks like success.

There are no releases in the retrieved metadata, so there is no versioned upgrade path to reason about. The last push is recent, which suggests active development, but without releases you are tracking the default branch. If you adopt this, pin a commit rather than following `main`.

The first thing to verify is the doctor output against a real project, not a toy one, because the project-specific tool checks are where stack mismatches surface. The second is the lock behaviour under a deliberately conflicted workload: point two agents at work items that touch the same file and watch what the framework does. The README describes the lock system as preventing conflicts but does not describe the failure path, and that is the behaviour you are actually betting on.

Editorial conclusion

Adopt this if you already run Claude Code interactively, have a repository large enough to split into many independent work items, and want the lock and restart logic handled for you. Do not adopt it if you expect the same behaviour from OpenCode or Codex, because the README states readiness detection, context parsing and health checks are Claude Code specific and will be degraded or inert. Before a first real run, verify three things: that `claude-code-agent-farm doctor --path /path/to/project` passes cleanly, that your `cc` alias matches the documented form with `--dangerously-skip-permissions`, and that the config you pick points at the right stack. The permissions flag is the item to think hardest about, since it is what makes unattended parallel editing possible in the first place.

Official sources

1. Dicklesworthstone/claude_code_agent_farm on GitHub
2. Issues
3. README