Parallel work

Separate task worktrees

Each managed Task runs in its own worktree by default. Claude Code can edit one Task while Codex edits another without sharing a mutable checkout. A second writer for the same Task is blocked before a round starts. Current branch and full-access runs use the shared checkout and are project-exclusive.

Overlap and waiting

Territory chips warn when two Tasks intend to touch the same ground. Iterel checks that at four levels:

• Files and folders — the same file, or a parent or child folder of it.
• Design frames — the same bound frame.
• Exported symbols — two Tasks editing different exports of one file are cleared to run together, but only when each has its own worktree. On a shared checkout they would write the same file, so they take turns. If Iterel cannot account for every change in a file, it treats the whole file as taken.
• Interfaces — the same API route or the same database table, even when the two Tasks share no file at all. This is the collision a line-based merge cannot see: two engines can break the same route from files that never conflict.

A Task's territory is not only what it declared. After each round Iterel folds in what the round actually changed, so the next scheduling decision is made against real ground rather than a prediction.

With separate worktrees an overlap is a merge-risk warning, not proof of a live workspace collision: choose Wait or Run isolated. Iterel never lets that choice override a hard same-worktree owner.

Changes outside Iterel

Iterel watches the bound checkout and active Task worktrees for relevant source changes. An edit without a managed claim is labeled External changes on this computer. Iterel preserves it: it does not kill the editor or engine, reset or stash files, move work, or delete branches.

The project terminal opens the shared checkout. A Task terminal opens that Task's exact worktree. Engines started in Terminal.app, another editor, or another harness remain unmanaged; Iterel can observe their file changes but cannot reliably name or control the process.

Stable checks

Verification records the commit, source fingerprint, and change epoch before and after each attempt. If source changes while checks run, Iterel preserves the output and marks the attempt Invalidated by concurrent changes rather than failed. It waits for a stable workspace and retries once. A second invalidation leaves Checks stale and never loops.

Accept remains available with the existing stale-check warning. A later valid attempt clears staleness only when it covers the current snapshot.

Availability

Parallel work is available for Iterel-launched, Task-scoped engines. The ownership and snapshot-verification acceptance suite passed on 2026-07-18. Independently launched processes remain outside Iterel's ownership guarantee and appear only as external changes.