[Bug bounty] block-monk.sh hooks script has false-positive matches on "monk" substrings in process names (e.g., "monkey", "monk-notify")

[arielbarbaro]

Stage: connect · Severity: medium (hook interference) · OS: macOS · Agent: Claude · plugin/agent: v0.1.52

Summary

The block-monk.sh hooks script uses a regex pattern that can produce false-positive matches on process names containing "monk" as a substring, such as "monkey", "monk-notify", "monkeyboard", or user-defined scripts that happen to include "monk" in their name.

Root cause

The regex in hooks/block-monk.sh matches process names using a pattern that does not enforce strict word boundaries around "monk". The current pattern:

# Pattern captures: monkd?(\.(exe|cmd|bat|ps1))?
# Character class: [^[:space:]...]

While the comment says "monkey is not matched", the regex does not use proper word boundary anchors (\b). The character class [^[:space:]...] only checks for non-whitespace characters around the match, which fails to distinguish between:

• monk (Monk process - should match)
• monkd (Monk daemon - should match)
• monkey (unrelated process - should NOT match but DOES)
• monk-notify (user script - should NOT match but DOES)

Reproduction

1. Install Monk plugin in Claude Code
2. Create a script named monk-notify.sh or run a process named monkey
3. The block-monk.sh hook fires and incorrectly identifies these as Monk processes
4. The hook may block or interfere with the unrelated process

Fix

Replace the regex with proper word boundary matching:

# Use \b word boundary anchors
if [[ "$process_name" =~ (^|/)(monkd?)(\.(exe|cmd|bat|ps1))?$ ]]; then
  # Match only "monk" or "monkd" at word boundaries
fi

Or use grep -w (word match) instead of the current character class approach:

if echo "$process_name" | grep -qE '(^|/)monkd?(\.(exe|cmd|bat|ps1))?$'; then

Dedup

Searched for "block", "hook", "false", "process". No existing issue covers this specific regex false-positive problem. Related issue #101 addresses hook path resolution but not the regex matching logic.

[nooga]

Thanks for the report, but I can't reproduce this against current main. I ran the exact cases through the live fallback path (forcing it via a nonexistent MONK_AGENT_PATH) on both hooks/block-monk.sh and .antigravity-plugin/hooks/block-monk.sh:

command	result
monkey patch	ALLOWED (correct)
monk-notify.sh restart	ALLOWED (correct)
monkeyboard --start	ALLOWED (correct)
monk deploy	BLOCKED (correct)
monkd --serve	BLOCKED (correct)

The current regex's trailing ([[:space:]]|$) after monkd? already enforces a right-hand boundary — "monkey" can't match because "e" satisfies neither whitespace nor end-of-string. The regex text quoted in the report (a bare character class with no boundary) doesn't match what's actually in either file, on this commit or any prior one I could find. Closing as not reproducible.