[Bug bounty] Windows block-monk guard fails open when helper errors

[nexicturbo]

Bounty eligibility

• I have signed up at monk.io with this GitHub account (nexicturbo)
• I installed the plugin and reproduced this against the Windows hook path
• I have starred the repository

Stage

operate

Coding agent

OpenAI Codex 0.125.0

Plugin / agent version

0.1.45

Repro steps

On Windows, hooks/block-monk.ps1 delegates every Bash command to the installed monk-agent hook block-monk helper. If that helper exists but exits unsuccessfully, the script immediately exits with the helper's code instead of running its native fallback.

The following uses a stock Windows executable as a deterministic stand-in for an installed helper that fails during invocation. It does not touch a Monk cluster:

$env:MONK_AGENT_PATH = "$env:SystemRoot\System32\net.exe"
$payload = '{"tool_input":{"command":"monk cluster list"}}'
$output = $payload |
  powershell.exe -NoProfile -ExecutionPolicy Bypass `
    -File .\hooks\block-monk.ps1 2>&1

[pscustomobject]@{
  ExitCode = $LASTEXITCODE
  HasDenyDecision = (($output -join "`n") -match 'permissionDecision')
  Output = ($output -join "`n")
}

On v0.1.45 this returns:

ExitCode       : 1
HasDenyDecision: False
Output         : The syntax of this command is: ...

There is no deny JSON, so the PreToolUse host receives no block signal for the direct monk command. The same fail-open state can occur during an interrupted update, with an incompatible helper, or when the helper fails to initialize.

A second variant is an existing executable that returns success but emits malformed output. Before the fix, that output is relayed and trusted without validation, again bypassing the native command check.

Expected behavior

The shell guard should keep blocking a direct monk CLI invocation whenever the helper cannot return a valid PreToolUse decision. Ordinary commands must remain allowed and produce no output.

Actual behavior

Any existing helper path bypasses the PowerShell fallback. A nonzero helper result is propagated, while a successful malformed response is relayed as if it were a valid decision. Neither path produces the deny JSON that blocks the direct CLI invocation.

This defeats the guard precisely when the installed companion is partially updated, incompatible, or otherwise unhealthy. Running the CLI directly can desynchronize the cluster state that Monk manages, which is the failure the hook exists to prevent.

Proposed fix

Capture and validate the helper response. Trust it only when it exits successfully and returns a structured PreToolUse permission decision; otherwise discard its output and run the native PowerShell parser. A Windows regression should cover both a nonzero helper and a successful helper with malformed output, for blocked and allowed commands.

Severity (my guess)

major

Environment

• OS: Windows 11 Home 64-bit, build 26200
• PowerShell: 5.1.26100.8894
• monkd: not involved; the failure occurs in the host hook before runtime access
• Target cloud: none
• Integration: Claude Code-compatible Windows PreToolUse hook