Summary

When creating a new worktree through the Orca app, the setup-runner.sh it generates is built from the orca.yaml of the primary checkout, not the orca.yaml at the tip of the target worktree's branch. If your primary checkout is on an older branch that predates an orca.yaml change, every new worktree you create — even off main — runs the stale setup script.

Repro

1. On branch main (say at commit A), add a line to orca.yaml scripts.setup: echo "new line". Merge to main.
2. Switch your primary checkout to any branch that predates that commit: cd ~/projects/orca && git checkout some-old-feature-branch.
3. From the Orca app, create a new worktree off main.
4. Expected: the new worktree's orca.yaml has the new line, and .git/worktrees/<name>/orca/setup-runner.sh includes it.
5. Actual: the new worktree's orca.yaml has the new line (git is correct), but setup-runner.sh contains only the pre-change version — because it was generated from the primary checkout's current HEAD yaml.

Impact

• Any orca.yaml change rolled out via a PR is invisible to teammates until their primary checkout is on a branch that contains the change.
• Silent failure mode: yaml looks right on disk, setup script disagrees, no warning logged.
• Surfaces in practice when a team uses orca.yaml for environment bootstrap (e.g. populating secrets, agent skills, etc.) — teammates think their setup is broken when actually the runner is stale.

Expected behavior

setup-runner.sh should be generated from the target worktree's orca.yaml (the file that git checked out into the new worktree), not the primary checkout's HEAD.

Relevant code

src/main/hooks.ts — the orca.yaml parser and createWorktreeRunnerScript. The loadHooks(repo.path) call in getSetup/getArchive reads from the repo's primary path rather than the worktree path.

Workaround

Keep primary checkout on main (or whatever branch has the canonical orca.yaml) when creating new worktrees. Brittle — easy to forget when in the middle of a feature branch.

Made with Orca 🐋