fix: self-install Defender deps and load from plugin root

[hiskudin]

Summary

• Adds a SessionStart hook that runs npm install in CLAUDE_PLUGIN_ROOT the first time a session starts after plugin install. Subsequent sessions skip it (guarded by [ -d node_modules ]).
• Fixes the scan-tool-result.mjs script to load @stackone/defender from the plugin's own node_modules using createRequire, instead of looking in the user's project directory (which would silently fail for most users).

Why this was broken

The plugin cache at ~/.claude/plugins/cache/stackone-marketplace/... has no node_modules. The previous import("@stackone/defender") would silently process.exit(0) on every hook invocation, meaning Defender never actually ran.

Test plan

• Install plugin fresh, start a session — npm install runs once in plugin root
• Start a second session — install step is skipped
• WebFetch or Bash returning injection content is blocked (exit 2)
• Clean benign tool output passes through unblocked

🤖 Generated with Claude Code

---

Summary by cubic

Ensure the Defender hook runs by self-installing deps and resolving modules from the plugin root. Tightens the install guard to avoid skipping after a partial install, fixing silent no-ops where @stackone/defender failed to load.

• Bug Fixes
  • Add SessionStart hook to run npm install --prefix "$CLAUDE_PLUGIN_ROOT" --silent on first session; skip only when node_modules/@stackone/defender exists.
  • Update scan-tool-result.mjs to load @stackone/defender via createRequire anchored at CLAUDE_PLUGIN_ROOT, blocking malicious Bash/WebFetch/WebSearch output.

^{Written for commit 7e13d63. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="hooks/hooks.json">

<violation number="1" location="hooks/hooks.json:8">
P2: The install guard is too broad: checking only `node_modules` can permanently skip dependency installation after a partial/corrupt install.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[Copilot]

Pull request overview

This PR fixes Defender not running in Claude plugin environments by ensuring dependencies are installed into the plugin cache directory and by resolving @stackone/defender from the plugin’s own node_modules rather than the user’s project.

Changes:

• Add a SessionStart hook to run npm install in CLAUDE_PLUGIN_ROOT (guarded by presence of node_modules).
• Update scan-tool-result.mjs to load @stackone/defender via createRequire rooted at the plugin directory.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
scripts/scan-tool-result.mjs	Switch Defender module resolution to the plugin root so the hook can actually load Defender in cached plugin installs.
hooks/hooks.json	Add a SessionStart hook to self-install Node dependencies into the plugin root on first run.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cubic-dev-ai]

0 issues found across 2 files (changes from recent commits).

_{Requires human review: This PR introduces runtime dependency installation (npm install) and modifies module resolution logic, which impacts plugin initialization and security hooks.}