claude-plugins-official

This is a known false positive in security-guidance v2.0.0. The rule currently lacks a path filter to exclude documentation files. As a temporary workaround, you can either ignore these warnings in .md/.mdx/.rst files or manually edit hooks/patterns.py to add path_filter: lambda p: not p.endswith(_DOC_EXTS) to the rule. A proper fix is expected in a future update; track issue #2045 for status.

Update plugins/security-guidance/hooks/llm.py to nest the schema under output_config.format instead of the deprecated top-level output_format. Specifically, replace "output_format": {"type": "json_schema", "schema": output_schema} with "output_config": {"format": {"type": "json_schema", "schema": output_schema}}. If you're on the adaptive-thinking branch, merge effort into the existing dict: change payload["output_config"] = {"effort": "high"} to payload["output_config"]["effort"] = "high". The patch is in issue #2097. This resolves the 400 error and prevents guardrail failing open.

The security-guidance plugin hook is emitting a denial via sys.exit(2) without a JSON payload, causing a generic denial message. Upgrade the plugin to a version that prints a proper JSON denial with permissionDecisionReason. If an immediate upgrade isn't possible, manually patch the hook script (e.g., security_reminder_hook.py) to replace bare sys.exit(2) with:

import json
print(json.dumps({
    "hookSpecificOutput": {
        "hookEventName": "PreToolUse",
        "permissionDecision": "deny",
        "permissionDecisionReason": f"{rule_name}: {reminder[:120]}"
    }
}))
sys.exit(0)

This provides context (matched pattern, risk category) in the UI. Track the upstream fix to remove the need for local patches.

The hook outputs plain text instead of JSON. Edit hooks/security_reminder_hook.py line 272: replace print(reminder, file=sys.stderr); sys.exit(2) with print(json.dumps({"decision": "block", "reason": reminder})); sys.exit(2). This outputs valid JSON, resolving the validation error.

Root cause: a Microsoft Store/MSIX Python (e.g. PythonSoftwareFoundation.Python.3.10, resolved from PATH as python3.10/python3 from WindowsApps) runs inside a Windows AppContainer sandbox. It passes python -c probes and reports a real version, but is denied read access to another app's data folder (e.g. %APPDATA%\Roaming\Claude\...), so it reports Errno 2 for files that demonstrably exist. sg-python.sh commits to this interpreter in Pass 1 and never falls through to the working python.org install, so every hook (UserPromptSubmit, PostToolUse, Stop) fails — and Stop with asyncRewake: true re-triggers the error on every turn.

Fix option A — remove the sandboxed interpreter from PATH: uninstall the Store Python (Settings > Apps) or disable it under Settings > Apps > Advanced app settings > App execution aliases, then install Python from python.org and verify with where python / where python3 that the real interpreter resolves first.

Fix option B — patch sg-python.sh so the probe verifies real script execution, not just -c. Write a throwaway script into the SAME directory as the target script (NOT /tmp — that is inside the sandbox's allowed set and won't reproduce the failure):

can_run_script() {
    local target_dir="$1"; shift
    target_dir="$(dirname -- "$target_dir")"
    local tmp="$target_dir/.sg-python-probe-$$.py"
    printf 'pass\n' > "$tmp" 2>/dev/null || return 1
    if command -v cygpath >/dev/null 2>&1; then
        "$@" "$(cygpath -w "$tmp")" >/dev/null 2>&1
    else
        "$@" "$tmp" >/dev/null 2>&1
    fi
    local rc=$?
    rm -f "$tmp" 2>/dev/null
    return $rc
}

Then gate each exec site in all three passes on is_sdk_compatible "$v" && can_run_script "$1" "$cmd" ($1 = the real target script path). The shim then skips the sandboxed Store python3.10/python3 and falls through to the python.org python (e.g. C:\PythonXXX\python.exe).

Verify with: bash sg-python.sh "$PLUGIN_ROOT/hooks/security_reminder_hook.py" — it should succeed instead of failing with Errno 2.