concurrent-agents

# Concurrent Agents Steve runs many Claude Code and Codex sessions against this one checkout on purpose, often on the same branch or file. Default assumption on every task: the working tree is shared branch state. Read existing changes before editing them, and never reset, clean, stash, or overwrite local work without explicit authorization. ## Read before you edit Before touching a file that already has uncommitted changes, re-read it and build your edit on top of what's there. Landing your own complete fix over a peer's in-progress one has happened repeatedly — "another agent landed its own complete fix for the exact same bug in the exact same file, overwriting my in-progress edits on disk." There is no conflict, no warning; the edit vanishes. ## Diagnosing "did someone revert my work" — correctly `git diff --stat` line counts are not evidence of a revert — a refactor can show the same magnitude of deletions. An agent once announced a revert from stat counts alone and was wrong; it cost a full investigation to disprove. Before you say "reverted" out loud, run: ```bash git log --oneline <base>..HEAD # what actually landed, in order git diff <base>..HEAD -- <path> # the real hunks for the files in question ``` Read the hunks: a revert removes logic and puts nothing equivalent back; a refactor removes the same lines and adds different code doing the same job. Only the hunks tell you which happened — never `--stat` alone. ## Shallow or grafted worktrees Shallow clones and grafted worktrees do not have complete ancestry. Treat `git log -S` and `git merge-base --is-ancestor` results at their boundary as inconclusive; fetch complete history or verify the date through the remote commit or pull-request record before calling a change the first occurrence. ## Branch operations follow checkout ownership In a dedicated task-owned worktree, create or switch to an available branch needed for the task without asking permission. Git worktrees isolate files; the Git refs are shared, so never move, rewrite, or delete a branch checked out in another worktree. If a branch name is already used, choose another available name. Preserve and carry or reapply local changes; do not stash or discard them. Before creating or switching branches, record `git status --short --untracked-files=all` and classify every staged, unstaged, and untracked path. A switch carries the whole index and worktree, so proceed only when every dirty path belongs to this task. If any path is unrelated or incomplete, keep the checkout in place and report the exact paths without asking again. In a shared checkout, keep its branch unchanged. For an explicit `/ship` or PR-publishing request that cannot safely use the current checkout, follow `new-branch` to create a managed task-owned worktree from the correct base, carry only the requested task's changes, and create its task branch without asking. For other work, use the current branch unless the user gave an exact branch operation. Keep platform-assigned Builder.io and Fusion branches in place. ## Timing the next branch Before creating a branch, inspect the active worktrees and dirty paths: ```bash git status --short git worktree list --porcelain gh pr list --head "$(git branch --show-current)" --state open ``` In a task-owned worktree, do not require a checkpoint or `ship:push` just to create a fresh branch; preserve and carry the current task's changes. For post-merge rotation, follow `new-branch`'s dedicated safety checks. For an explicitly authorized branch-wide checkpoint, publish one complete snapshot with `corepack pnpm ship:push -m "<specific change>"`. Do not publish separate checkpoints for delegates or intermediate edits. ## Before you ship Before you commit, push, or merge, check `git log --oneline -5`, `git status`, and `gh pr list --head <branch>` for the current PR. If the work you were about to do just landed, continue from the latest branch snapshot. Do not rebase or merge `origin/main` just to clear behind status or restart checks. Rebase or merge it only when GitHub reports an actual conflict; for a shared branch, prefer a normal merge. ## Reading a Codex peer's intent Relaying between agents by hand is the user's most tedious job — don't make him paste what a Codex session is doing. Read its transcript yourself: ```bash ls ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl ``` Each line is a JSON event; `payload.type == "user_message"` is what the user asked, `payload.type == "agent_message"` is what it answered — enough to learn a peer's task without interrupting it or the user. ## Related - `new-branch` — safe branch creation in task-owned worktrees and automatic task-worktree isolation for shipping from shared checkouts. - `ship` — the commit/push/PR workflow for the complete branch snapshot.