Open-source IDE Orca runs parallel coding agents in isolated git worktrees

Orca is an open-source desktop application built to host command-line coding agents — Claude Code, Codex, OpenCode and several others — and it rests on one premise: add a repository, and every task gets its own git worktree, its own branch and its own agent. Two agents never edit the same files, finished work arrives as a pull request, and Orca notifies you when an agent completes a task or stops to ask a question.

That is the picture from a detailed first-week write-up on dev.to, whose author — a VS Code user of fifteen years — calls Orca the first IDE to make them consider switching. The account covers Orca 1.4.253 and 1.4.255 on macOS, with Claude Code on Sonnet 5.5, and the app installs from onorca.dev.

GitHub issues become the task queue

Orca's Tasks view gathers the issues of every repository you add into a single table, each row carrying a Start button. Pressing it opens a worktree-creation dialog in which the issue's URL becomes the agent's first prompt. The author's warning: the default view also pulls in upstream forks — 250 pages of other people's issues in their case — so filter by project before touching anything.

The first run sent two issues into two worktrees in roughly two minutes of clicking. One agent fixed a bug in how the author's finance app parsed broker screenshots and opened a PR in 2 minutes 31 seconds, with 15 tests passing; it was merged after CI went green. The second agent stopped to ask a question, because its issue pointed at a spec section that existed only in an unmerged PR; once told to write the spec from the issue text, it opened its PR in 5 minutes 29 seconds.

Planning on a big model, writing on a cheaper one

The author divides the labour: a top-tier model (Fable 5.2 or Opus) produces the plan and splits the tasks, while every code-writing agent runs on Sonnet. The model is set once in Orca's settings, and Orca appends --model sonnet to each launch so nothing depends on per-task memory. A status bar tracks Claude plan usage — two Sonnet agents working for 22 minutes moved it from 40% to 41% — a reminder, the author argues, that token counts alone hide how fast a bigger model drains a plan.

Orca also ships a CLI, present in every Orca terminal, whose worktree-create command takes a repo, an agent, a model and a prompt. That is now the author's dispatch route: describe the problem to Claude, let it write the briefs and launch the agents, then come back to review PRs.

Six failures, six rules

Most of the post catalogues what broke in week one and the guardrail each failure produced.

• Claude Code suggests merging as a next step once it finishes, and accepting is one keypress away. Every brief now ends with "open a PR, never push to main, never merge"; the author merges personally, after CI and a diff read.
• Orca's default permission mode is Full access, which launches Claude Code with --dangerously-skip-permissions, and a private repo on a free GitHub plan offers no branch protection. The author added a pre-push hook, shared by all worktrees, that rejects pushes to refs/heads/main.
• One local clone sat 484 commits behind origin, and an agent can only report on what its clone knows — stale code yields authoritative answers about the wrong version. Worktrees are now based on origin/main via Orca's set-base-ref command.
• A brief citing a document that lives in an unmerged PR leaves the agent waiting for an answer. Context is now pasted into the issue itself, with links as optional extras.
• One agent reported a fix as live in production after the deploy job passed, though the GitOps controller never rolled out the new image — it had trusted the most recent passing step. Agents must now check the version actually being served.
• A colour fix grew into three infrastructure changes, one merged without waiting for CI, as the original instruction got buried further down the conversation. When work changes type, a new worktree and a new brief are opened.

Day-one friction to expect

Other findings: each new agent in Full access mode shows Claude Code's bypass-permissions warning and waits for acceptance, stalling a first parallel run; shell aliases and .zshrc never reach agents because Orca runs binaries directly, so environment variables belong in ~/.claude/settings.json; hooks should use the stable Homebrew bin path rather than a versioned Cellar path that the next upgrade deletes; fresh worktrees contain only tracked files, so .env files and local helpers must be copied in; and screenshots paste with Ctrl+V rather than Cmd+V. System notifications are worth enabling.

Why it matters

Orca points at where development tooling is going: the IDE as an orchestration layer for agents rather than an editor, with git worktrees as the unit of isolation that lets several of them work one repository at once. The dev.to account matters just as much for what it says about practice. None of the week's failures were crashes; they came from defaults — full-access permissions, unguarded main branches, briefs referencing documents that do not exist — that only human process can close. Anyone pointing parallel agents at a real backlog will need rules like these, whatever tool they run.