Contain linked project skill roots inside the repository - #2990
Open
ylcn91 wants to merge 1 commit into
Open
Conversation
## What was wrong
`scanSkillRootFiles` opened a non-recursive project skill root before
resolving it against the workspace boundary, so a root that is itself a
symlink was scanned wherever it pointed. A checked-in `.claude/skills`
link to a directory outside the repository put every skill under it into
the project's skill and command lists, with `origin: "project"`. The
recursive shape already resolved the same plumbed `boundaryPath` before
walking, and `docs/provider-plugin-api.md` already states the rule for
both shapes: a symlink out of a project root is followed within the
workspace for a plain root and within the repository root for a root
that walks ancestors or that the plugin resolved.
## What changed
`resolveRecursiveRootPath` becomes `resolveBoundedRootPath` and the flat
skill root scan consults it, so both shapes enforce one containment rule
against the same `boundaryPath`. A root link that stays inside the
repository still resolves and is still scanned, and user-origin roots,
which carry no boundary, are unaffected.
No field or message on the server/host-daemon wire changed, so
`HOST_DAEMON_PROTOCOL_VERSION` stays at 178.
## How you verified
- Added two `command-discovery` regressions: a project `.claude/skills`
root symlinked outside the workspace discovers nothing, and one
symlinked to `.agents/skills` inside the workspace still discovers its
skill. The first fails on the parent commit
(`expected [ { name: 'leaked', …(4) } ] to deeply equal []`) and
passes here; the second passes on both.
- `pnpm exec turbo run test --filter=@bb/host-daemon --force`: 46 files,
574 tests passed (1 failed before the fix).
- `pnpm exec turbo run typecheck --filter=@bb/host-daemon`: passed.
- `BB_TEST_TIMEOUT_SCALE=3 pnpm exec turbo run test
--filter=@bb/integration-tests --force --env-mode=loose --
native-roots-golden`: 22 provider golden fixtures passed unchanged,
including the cursor symlink-boundary and grok symlink variants.
- Drove `listHostCommands` with the shipping claude-code declaration
(`.claude/skills`, `ancestors: true`) over the issue's fixture: the
escaping root reported `["leaked"]` before and `[]` after, while the
in-repository link reported `["in-repo"]` in both.
Fixes get-bb#2769
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human comments
What was wrong
scanSkillRootFilesopened a non-recursive project skill root beforeresolving it against the workspace boundary, so a root that is itself a
symlink was scanned wherever it pointed. A checked-in
.claude/skillslink to a directory outside the repository put every skill under it into
the project's skill and command lists, with
origin: "project". Therecursive shape already resolved the same plumbed
boundaryPathbeforewalking, and
docs/provider-plugin-api.mdalready states the rule forboth shapes: a symlink out of a project root is followed within the
workspace for a plain root and within the repository root for a root
that walks ancestors or that the plugin resolved.
Issue: #2769. Investigation report: https://get-bb.github.io/reports/issues/2769.html
What changed
resolveRecursiveRootPathbecomesresolveBoundedRootPathand the flatskill root scan consults it, so both shapes enforce one containment rule
against the same
boundaryPath. A root link that stays inside therepository still resolves and is still scanned, and user-origin roots,
which carry no boundary, are unaffected.
No field or message on the server/host-daemon wire changed, so
HOST_DAEMON_PROTOCOL_VERSIONstays at 178.How you verified
command-discoveryregressions: a project.claude/skillsroot symlinked outside the workspace discovers nothing, and one
symlinked to
.agents/skillsinside the workspace still discovers itsskill. The first fails on the parent commit
(
expected [ { name: 'leaked', …(4) } ] to deeply equal []) andpasses here; the second passes on both.
pnpm exec turbo run test --filter=@bb/host-daemon --force: 46 files,574 tests passed (1 failed before the fix).
pnpm exec turbo run typecheck --filter=@bb/host-daemon: passed.BB_TEST_TIMEOUT_SCALE=3 pnpm exec turbo run test --filter=@bb/integration-tests --force --env-mode=loose -- native-roots-golden: 22 provider golden fixtures passed unchanged,including the cursor symlink-boundary and grok symlink variants.
listHostCommandswith the shipping claude-code declaration(
.claude/skills,ancestors: true) over the issue's fixture: theescaping root reported
["leaked"]before and[]after, while thein-repository link reported
["in-repo"]in both.Fixes #2769