EnterWorktree leaves a committed project skill unavailable in 2.1.296 (Unknown skill)

Preflight checklist

• [x] Searched open issues for "Unknown skill" worktree, EnterWorktree project skill, worktree skill registry, and skill discovery worktree; no current duplicate appeared.
• [x] This is one bug.
• [x] Reproduced on the currently installed Claude Code, 2.1.296.

This is the current-version replacement for #88931, which was stale-closed today with an explicit request to open a new issue if the behavior remained relevant. #28041 is different: that issue concerns uncommitted .claude/ content not being copied into a newly created worktree. Here the skill is committed on the worktree branch, present on disk, and the session enters an already existing linked worktree.

What's wrong?

After EnterWorktree succeeds, the project-skill registry still cannot invoke a committed SKILL.md that exists only on the entered worktree branch.

I ran the following control sequence in one non-interactive session on 2.1.296:

1. Skill(skill: "probe-baseline")

• Result: Launching skill: probe-baseline

1. EnterWorktree(path: "$P/wt")

• Result: Entered worktree at .../wt on branch probe-branch. The session is now working in the worktree.

1. Bash(command: "pwd; ls -la .claude/skills")

• pwd was $P/wt
• the listing contained both probe-baseline and probe-worktree-only

1. Skill(skill: "probe-worktree-only")

• Result: <tool_use_error>Unknown skill: probe-worktree-only</tool_use_error>

1. Waited 160 seconds in the same process with a completed Bash until-loop.
2. Repeated Skill(skill: "probe-worktree-only")

• Same Unknown skill result.

The baseline control proves project skills loaded from the launch checkout. The cwd and directory listing prove the worktree transition and committed skill are present. The second failure rules out the registry's normal rescan window.

The run used --setting-sources project,local, a strict empty MCP config, and no plugins. bypassPermissions was limited to this throwaway repository. There were no permission denials. I did not read the worktree-only SKILL.md manually or substitute its instructions after the tool failure.

What should happen?

After EnterWorktree, project-skill discovery should re-root at the entered worktree (or include it). A committed skill visible under the session's current .claude/skills/ should be invocable in that session.

If the registry intentionally remains fixed, Unknown skill should at least name the roots it searched. Right now the session says it entered one tree while Skill silently resolves another.

Minimal setup

P=$(mktemp -d)
git init -q -b main "$P"
cd "$P"

mkdir -p .claude/skills/probe-baseline
printf '%s\n' \
  '---' \
  'name: probe-baseline' \
  'description: Control skill in the launch checkout.' \
  '---' \
  'Output the exact token BASELINE_SKILL_RAN and stop.' \
  > .claude/skills/probe-baseline/SKILL.md
printf 'probe\n' > README.md
git add -A
git commit -qm base

git checkout -qb probe-branch
mkdir -p .claude/skills/probe-worktree-only
printf '%s\n' \
  '---' \
  'name: probe-worktree-only' \
  'description: Skill that exists only on the worktree branch.' \
  '---' \
  'Output the exact token WORKTREE_SKILL_RAN and stop.' \
  > .claude/skills/probe-worktree-only/SKILL.md
git add -A
git commit -qm wt
git checkout -q main
git worktree add -q "$P/wt" probe-branch

Launch Claude Code from $P, invoke the six tool calls above in order, and do not read the worktree-only file manually.

Environment

• Claude Code: 2.1.296
• Model used for the probe: Claude Sonnet 5.5
• Platform: Anthropic API / Claude Max
• OS: Linux
• Mode: non-interactive claude -p, stream JSON