security-guidance plugin hook fails with ENOENT in local-agent-mode-sessions staging, causing infinite retry/notification loop

Corroborating this from a separate environment — same plugin ID (plugin_01YBNfaNwQztYsnUydt8m47G), same hook (security_reminder_hook.py), same infinite-retry-no-backoff pattern, same misleading "Background security review found issues" notification framing.

Differences from the original report, likely just environment variance rather than a different bug: our Python interpreter was the Microsoft Store app-execution-alias stub (AppData\Local\Microsoft\WindowsApps\python3.13.exe) rather than a pythoncore install, and our local ~/.claude/settings.json / per-session rpm/manifest.json referenced marketplace name knowledge-work-plugins rather than claude-plugins-official for the same plugin ID.

One additional data point: we saw the hook fire as a synchronous PostToolUse:Edit hook failure (not just the periodic background notification), immediately after an Edit tool call — so it's not confined to whatever triggers the periodic "security review" notification; it's wired into normal tool-call hook dispatch too.

We also independently reproduced the fix: adding explicit "security-guidance@<marketplace>": false entries to enabledPlugins in ~/.claude/settings.json, followed by a restart, per the original report's workaround.

Update from our side: we've now tried every local-config lever suggested here, in order —

"security-guidance@...": false in enabledPlugins — did not stop the loop
Fully removing the enabledPlugins entries entirely — did not stop the loop
Fully killing all claude.exe processes via Task Manager, a full system reboot, and a fresh app start — the identical ENOENT/"Background security review found issues" loop is still firing afterward

This rules out local settings.json state and even a full process/OS restart as a fix, and reinforces the earlier point that the failing per-session rpm/ staging path isn't something a client-side restart clears. At this point it looks like it'd need a fix shipped by Anthropic rather than anything actionable locally.

Related reports: #95727 and #94634.

I reproduced a narrower failure in the public launcher: sg-python.sh executes Python directly, so a missing script produces interpreter exit 2, although no review ran. The Stop hook enables asyncRewake, whose documented wake-up condition is exit 2. Its fixed summary says “Background security review found issues”. The Python stop_hook_active guard cannot run when that script is missing.

Minimal reproduction from the repository root, with Python 3 installed:

sg_repro_dir=$(mktemp -d)
bash plugins/security-guidance/hooks/sg-python.sh "$sg_repro_dir/missing.py" </dev/null
echo "$?" # 2
rmdir "$sg_repro_dir"

A minimal mitigation is a script-path existence check before interpreter dispatch:

if [ "$#" -gt 0 ] && [ "${1#-}" = "$1" ] && [ ! -e "$1" ]; then
    echo "security-guidance: hook script not found: $1" >&2
    exit 1
fi

All six current hooks.json invocations pass a script path first. This preserves interpreter-option passthrough and directory execution; it does not remap legitimate review exit 2.

In a temporary copy on macOS, ten controlled comparisons passed: missing script, script exits 0/1/2, two -c cases, -m, -, no-argument stdin, and directory execution. Paths containing spaces were included. Only the missing-script case changed (2→1); the controlled finding stub retained exit 2, and existing outputs were unchanged. No security scan or model call ran.

This validates the launcher mitigation, not the full Desktop loop. Windows/Git Bash remain untested. It does not repair staging, address replayed notifications, or eliminate the check-to-exec race.

Analysis and local validation were prepared with AI assistance.