v1.33.2.0 fix: setup guards against Conductor worktree pollution of global install (#1446)

* fix(setup): skip Claude skill registration when run from a worktree of the global install

Add a guard before `ln -snf "$SOURCE_GSTACK_DIR" "$HOME/.claude/skills/gstack"`
that detects whether the target already exists as a separate real directory.
On macOS/BSD, `ln -snf SRC DST` does not replace a real DST — it creates
DST/$(basename SRC) → SRC inside it. Running ./setup from each Conductor
worktree of the gstack repo was leaking per-worktree child symlinks into the
global install, which Claude Code then picked up as separate top-level skills.

The guard uses `cd ... && pwd -P` to resolve the existing real dir and compare
against the source (mirroring setup's own `SOURCE_GSTACK_DIR` resolution).
When they differ, prints a four-line remediation hint naming both paths and
exits the Claude registration branch cleanly. Binaries still build locally.

The four other code paths through this branch are unchanged: fresh install,
retarget an existing symlink, self-rerun where the existing dir resolves to
the same source, and --local installs.

Includes 8 tests covering static guard placement, `pwd -P` resolution, the
remediation message, a behavioral reproduction of the BSD `ln -snf` child-
symlink bug, and every branch of the guard (skip on real-dir-elsewhere, allow
on fresh, allow on existing symlink, allow on self-rerun).

* chore: bump version and changelog (v1.33.2.0)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Garry Tan
2026-05-11 20:35:58 -07:00
committed by GitHub
parent 1a4f0c9c15
commit dc6252d1df
5 changed files with 302 additions and 27 deletions
+42
View File
@@ -1,5 +1,47 @@
# Changelog
## [1.33.2.0] - 2026-05-11
## **`./setup` no longer pollutes the global install when run from a Conductor worktree.**
## **Six-line bash guard catches the BSD `ln -snf` footgun that was leaking per-worktree symlinks into `~/.claude/skills/gstack/`.**
When you ran `./setup` from a Conductor worktree of the gstack repo itself (e.g. `~/conductor/workspaces/gstack/dublin-v1`), it would silently corrupt your global install. The "register this checkout as the active gstack" branch did `ln -snf "$SOURCE_GSTACK_DIR" "$HOME/.claude/skills/gstack"`. On macOS and BSD, when the destination is an existing real directory (your global git clone), `ln -snf` does NOT replace it. It creates a child symlink INSIDE: `~/.claude/skills/gstack/dublin-v1 → ~/conductor/workspaces/gstack/dublin-v1`. Claude Code reads every directory in `~/.claude/skills/` that contains a `SKILL.md`, so each leaked worktree showed up as its own top-level skill: `/dublin-v1`, `/wellington`, `/santiago-v1`, etc. The skill picker filled with noise.
The fix in `setup` checks whether `~/.claude/skills/gstack` is already a real (non-symlink) directory whose resolved `pwd -P` differs from `$SOURCE_GSTACK_DIR`. If so, refuse the `ln -snf`, print a four-line remediation hint, and exit the Claude registration branch cleanly. Binaries (`browse`, `design`, `make-pdf`, `find-browse`) still build locally for dev. The four other code paths through the same branch (fresh install, retarget existing symlink, self-rerun pointing to the same dir, `--local`) are unchanged.
### The numbers that matter
Source: `bun test test/setup-conductor-worktree.test.ts` — 8 tests covering every branch of the new guard plus a behavioral reproduction of the BSD `ln -snf` bug itself.
| Scenario | Before | After |
|---|---|---|
| `./setup` from worktree A with global install present | Leaks `~/.claude/skills/gstack/A → workspaces/gstack/A` | Skipped with remediation hint |
| `./setup` from N sibling worktrees over a week | N child symlinks accumulate inside global install | 0 leaks |
| Claude Code skill picker shows extra entries | Yes: `dublin-v1`, `wellington`, `santiago-v1`, etc. | No |
| Fresh install (no existing global) | Worked | Worked (unchanged path) |
| Re-running `./setup` from inside the global install | Worked | Worked (unchanged path) |
| Test coverage of the guard | 0 tests | 8 tests, all branches |
The behavioral test in `test/setup-conductor-worktree.test.ts` actually invokes `ln -snf SRC DST` against a real tmpdir to prove the macOS/BSD child-symlink behavior happens, then re-runs with the new guard to prove the leak doesn't. The bug is now documented in the test suite, not just the patch.
### What this means for builders
If you've been seeing extra top-level skills (`/dublin-v1`, `/wellington`, etc.) in Claude Code, that's the leak. Run `/gstack-upgrade` to pick up this fix, then manually remove the existing child symlinks: `cd ~/.claude/skills/gstack && find . -maxdepth 1 -type l -delete`. The guard prevents new leaks from `./setup` runs in any Conductor worktree of the gstack repo. If you actually want to register a worktree as the active gstack (rare, usually only when dogfooding a big in-progress change), remove the global install first: `rm -rf ~/.claude/skills/gstack && cd <your-worktree> && ./setup`.
### Itemized changes
#### Fixed
- **`setup`** — added Conductor worktree guard before `ln -snf "$SOURCE_GSTACK_DIR" "$CLAUDE_GSTACK_LINK"`. Checks `[ -d "$CLAUDE_GSTACK_LINK" ] && [ ! -L "$CLAUDE_GSTACK_LINK" ]` for a real directory, then `cd ... && pwd -P` to compare against the source. If they differ, sets `_SKIP_CLAUDE_REGISTER=1`, prints a remediation message naming both paths, and exits the Claude registration branch without touching the global install.
#### Added
- **`test/setup-conductor-worktree.test.ts`** — 8 tests (27 expect calls) covering: guard placement in `setup` before `ln -snf`, `pwd -P` resolution against `$SOURCE_GSTACK_DIR`, the skip-branch's remediation message, BSD `ln -snf` reproducer (proves the bug shape exists), guard skips when dest is real-dir-elsewhere, guard allows ln when dest doesn't exist, guard allows ln when dest is an existing symlink (upgrade-in-place), guard allows ln when dest already resolves to source (self-rerun).
#### For contributors
- The guard intentionally does NOT clean up pre-existing pollution inside `~/.claude/skills/gstack/`. Users must remove leaked symlinks manually (see "What this means for builders" above). Retroactive cleanup would require a separate migration script, filed for a future release if the manual remediation friction becomes noticeable.
## [1.33.1.0] - 2026-05-11
## **Long skills stop drifting away from their starting context.**