Plugin-manifest index leak when claude -p invoked from pre-commit hook — phantom-blob commit failures

Summary

When Claude Code CLI (claude -p) is invoked from within a .husky/pre-commit hook in a git-managed repository, the CLI appears to write dangling index entries for plugin-manifest paths (.claude-plugin/marketplace.json and plugins/*/.claude-plugin/plugin.json) into the active worktree's git index without writing the corresponding blobs. Subsequent git commit operations then fail with:

error: invalid object 100644 <sha> for '.claude-plugin/marketplace.json'
error: Error building trees

The phantom SHAs match the layout of ~/.claude/plugins/marketplaces/claude-code-plugins.bak/.

Environment

• Claude Code CLI: v2.1.114
• Platform: macOS (Darwin)
• Host: large multi-worktree repo with husky-managed pre-commit hook

Reproduction

1. Repo with .husky/pre-commit that invokes claude -p on staged diff.
2. Environment has plugins installed at ~/.claude/plugins/marketplaces/.
3. git commit. Hook runs, claude -p returns normally.
4. Observe: the worktree's .git/index now contains un-staged entries for .claude-plugin/marketplace.json + plugins/*/.claude-plugin/plugin.json pointing at SHAs absent from .git/objects/.
5. NEXT git commit fails tree-build with "invalid object" + "Error building trees".

Evidence

14 dangling index entries accumulated in a freshly-created worktree during a single session. git fsck confirmed the phantom SHAs are NOT in .git/objects/ but ARE referenced by the index. SHAs match the claude-code-plugins.bak/ marketplace directory layout.

Workaround shipped

Preventive strip BEFORE the claude -p invocation in our hook:

git rm --cached --ignore-unmatch \
  .claude-plugin/marketplace.json \
  'plugins/*/.claude-plugin/plugin.json' \
  >/dev/null 2>&1 || true

Commits succeed reliably after shipping this. But it shouldn't be necessary.

Expected behavior

claude -p should not mutate the active worktree's git index as a side-effect of its own plugin-manifest loading. Plugin manifests are a Claude-internal concept and should be fully isolated from host-repo git state.

Additional context

Only affects workflows where claude -p runs inside a git-aware environment. Interactive claude in a non-git directory has not (to our observation) caused the same leakage. Happy to help with any minimal-repro request.