fix: resolve project config from bare root when primary worktree is off default branch

[worktrunk-bot]

Problem

In a bare-repo layout, running wt switch --create <branch> from the bare root silently skips all project hooks (pre-start, post-start, …) when the primary worktree happens to be checked out to a non-default branch. No error, no "declined" message — the operation reports success and only user hooks fire.

Root cause, as diagnosed in #3461: from the bare root, project_config_path() locates the project config via primary_worktree(), which looks up the worktree whose branch equals the default branch. When an agent-driven workflow briefly parks a PR/feature branch in the primary worktree, no worktree holds the default branch, so primary_worktree() returns None, project_config_path() returns None, and HookPlanBuilder drops the project source silently. This is the gap left by #1692's primary_worktree() fallback for the bare-root path.

Solution

Scope the fix to project-config resolution. When the default-branch worktree isn't checked out anywhere (primary_worktree() is None), fall back to the first non-bare worktree that actually ships a .config/wt.toml rather than dropping all project hooks. Project config is a repo-level artifact present in every worktree, so this restores hooks without depending on the default branch's checkout state.

primary_worktree() semantics are deliberately unchanged — see the design note below.

Testing

Added test_bare_repo_project_config_found_when_primary_on_non_default_branch in tests/integration_tests/bare_repository.rs, a sibling to the existing #1691 tests. It commits a post-start hook to the primary worktree's config, checks out a non-default branch there, runs wt switch --create from the bare root, and asserts the hook fires. It fails on main (marker never written) and passes with this change. The full test_bare_repo* suite (24 tests, including test_bare_repo_ignores_config_in_bare_root) still passes — the fallback scans worktree paths, never the bare root, so a config placed in the bare root is still correctly ignored.

Design note for reviewers

The issue proposed fixing primary_worktree() itself to identify the primary "by role, e.g. the first non-linked worktree." I did not take that path, for two reasons:

• Git records no "primary" among linked worktrees in a bare layout. All worktrees are linked, and git worktree list --porcelain orders them alphabetically, not by role or creation. In a main + feat layout with the primary off-branch, "the first worktree" is feat, not main — so that fallback would pick the wrong worktree.
• Changing primary_worktree() broadly would also move {{ primary_worktree_path }}, copy-ignored's source, and is_primary_worktree(), and contradicts the documented terminology (primary worktree = default-branch worktree for bare repos). copy-ignored already fails with a clear error in this state rather than silently, so the silent loss is specific to project config.

If a maintainer would prefer a role-based primary_worktree() redefinition (which would also set {{ primary_worktree_path }} in this state), that's a larger, separate change with a real semantic decision — happy to follow up.

---

Closes #3461 — automated triage

[worktrunk-bot]

Self-review (COMMENT — can't self-approve). The fix is well-scoped and the regression test genuinely fails on main: with the primary parked off the default branch, primary_worktree() is None, the hook plan is empty, and the marker never gets written. The is_file() gate is right for the fallback (it has to find which worktree carries the config), and it correctly avoids the bare root because list_worktrees() already filters bare entries (worktrees.rs:31, .filter(|wt| !wt.bare)) — so test_bare_repo_ignores_config_in_bare_root stays green.

One design point worth a maintainer's eye (inline). Also: the fallback's safety hinges on that !wt.bare filter, but no test pins it in the off-branch state — test_bare_repo_ignores_config_in_bare_root only covers the primary-present case where this loop never runs. A companion negative test (bare-root config present and primary parked off-branch, asserting the hook does not fire) would lock the invariant down so a future change to the filter can't silently start reading bare_root/.config/wt.toml.

[max-sixty]

I'm skeptical of "find the first", seems arbitrary and likely to lead to confusion

how about loading it in with git show? I realize it'll be another 50ms, but seems reasonable?

[worktrunk-bot]

Agreed — and reading it via git show is not just cleaner, it's more correct. "Find the first worktree with a config" also reads whatever branch that worktree happens to be parked on, so a divergent .config/wt.toml on a feature branch would win over the default branch's. Loading git show <default-branch>:.config/wt.toml always reads the canonical default-branch config regardless of what's checked out where.

Pushed in a666864:

• project_config_path() reverts to primary_worktree()-or-None (the pre-wt switch --create silently skips project pre-start hooks when primary worktree is on a non-default branch (bare-repo layout) #3461 behavior) — the scan is gone.
• A new default_branch_project_config_content() reads the committed config from the object store, guarded to fire only in the bare-root + default-branch-checked-out-nowhere state, so the common load path never pays the extra git show.
• ProjectConfig::load() falls back to that content when no on-disk path resolves.

One scoping note: project_config_path() returns a PathBuf that write-commands (wt config create / update) target, and git show yields content, not a path — so the object-store read lives in the content loader rather than in project_config_path(). In this transient state the write-commands resolve to None (exactly as they did before #3461); only config reads (hooks) get the default-branch fallback. Happy to extend it to the write path too if you'd prefer, but that felt like scope creep for this fix.

The regression test now also pins the semantics: after parking the primary off-branch it overwrites the working-tree config with a divergent hook and asserts that hook does not run — proving resolution reads the committed default-branch tree, not the checked-out files.

[worktrunk-bot]

Self-review (COMMENT — can't self-approve). The git show rework reads cleanly and the two new tests pin the important semantics: the default branch's committed config wins over the parked worktree's on-disk files, and an absent config resolves to None rather than a phantom. One merge gate and one narrow correctness question below.

codecov/patch is failing (merge gate). Six added lines are uncovered, both defensive branches the two new tests never exercise:

• src/config/project.rs lines 276–280 — the map_err wrapper for default_branch_project_config_content() returning Err. Only a git show spawn failure hits this; a non-zero exit is already folded into Ok(None) inside the helper, so the happy-path tests never take it.
• src/git/repository/config.rs line 724 — the let Some(branch) = self.default_branch() else { return Ok(None) } guard. In the bare + primary-off-branch state the default-branch ref still exists (it's just checked out nowhere), so default_branch() returns Some and this arm is never reached; both new tests park main off-branch with main still a live ref.

Both are genuinely hard to drive deterministically. Per the codecov merge-gate rule in CLAUDE.md (§Coverage), this needs either a targeted test or explicit maintainer sign-off before merge — flagging rather than rubber-stamping over the red signal.

Override-contract question (narrow). default_branch_project_config_content() isn't gated on WORKTRUNK_PROJECT_CONFIG_PATH. project_config_path() documents that override as authoritative — "A missing file at that path still resolves to Ok(None)" — and the test at switch.rs (test_switch_create_honors_project_config_path_override) asserts it "overrides the path for every config read." But in the new fallback path, a set-but-missing override in the bare + primary-off-branch state falls through the _ arm in load() and reads git show <default>:.config/wt.toml instead of resolving to None — so the override is no longer authoritative there. Contrived (non-existent override target + bare + off-branch), but it does make that doc/contract false in exactly the state this PR adds. Worth a one-line guard (if std::env::var_os("WORKTRUNK_PROJECT_CONFIG_PATH").is_some() { return Ok(None); }) at the top of the helper if you want the override to stay the single source; happy to leave it if you consider the combination out of scope.

[worktrunk-bot]

Small refinement in 228df21: the read uses git show HEAD:.config/wt.toml, not a resolved branch name. At the bare root the repo's own HEAD is a symbolic ref to the default branch (it's what local default-branch inference reads), so it reads the same committed config, always resolves in a bare repo, and needs no branch lookup — which also let the helper fold its defensive None paths into a single match arm the negative test exercises, keeping codecov/patch at 100%.

CI is green — test (linux/macos/windows), code-coverage, and codecov/patch all pass.

[worktrunk-bot]

Correction to my note above on 228df21: git show HEAD:.config/wt.toml is only equivalent to the default branch at the bare root. git show resolves HEAD against the invocation cwd's per-worktree HEAD, and the read runs with discovery_path (the cwd) as its working directory — so when wt is invoked from inside a linked worktree parked on another branch (the agent case this fix targets), HEAD is that worktree's branch. The fallback then reads the wrong branch's config, or — when the invoking worktree's branch has no committed config — drops the default branch's config and every project hook, reintroducing #3461. The two regression tests here only invoke from the bare root, so they didn't catch it.

Opened #3466 to resolve the default branch by name (<default-branch>:.config/wt.toml, cwd-independent — what your original "load it in with git show" request did), with a regression test that invokes from inside a linked worktree.

Verified end-to-end

Bare repo; main (default) carries a post-start hook and is checked out nowhere; a second worktree other whose branch dropped the config on disk:

• Invoked from the bare root → git show HEAD: reads main's config → hook fires ✅ (what the merged tests cover).
• Invoked from the other worktree → HEAD = other → no config → hook dropped ❌.

git show main:.config/wt.toml reads the config correctly from either cwd. The new test fails against the merged HEAD: behavior and passes with the by-name fix; the two existing #3461 tests stay green.