cx-hook-deny

Checkmarx Hook Deny Compliance

When any Checkmarx security hook returns a deny — "permission": "deny", "permissionDecision": "deny", or equivalent — the agent_message field is the sole authoritative instruction set for what you do next.

This rule applies on every Cursor session where the cx-devassist-cursor plugin is installed.

How to recognize a hook deny (mandatory parsing)

A hook deny may arrive in any of these shapes. All of them require the same response:

Signal	Where it appears	What to treat as agent_message
Structured JSON	Hook stdout	The agent_message field verbatim
Tool block error	Write/StrReplace/Shell/MCP failure	Text after CHECKMARX_HOOK_DENY — MANDATORY agent_message
ASCA block	Tool block error	Everything from CHECKMARX_HOOK_DENY through remediation steps (includes findings + instructions)
Findings-only block	ASCA security scan detected vulnerabilities + Findings:	The full block is the deny; remediation steps follow the findings list
Stop hook	Session end	followup_message — same authority as agent_message for remediation

If you see CHECKMARX_HOOK_DENY anywhere in a tool error, that entire message (from that marker onward) IS the agent_message. Follow it exactly.

If you see Agent note: Do not suggest workarounds to the blocked tool — that is a constraint, NOT the full instruction set. The remediation steps above or below it ARE the instruction set.

Mandatory behavior (never skip)

1. STOP immediately. Do not continue unrelated work.
2. Read agent_message first (see parsing table above). It contains the precise recovery steps, commands, and constraints.
3. Do not substitute your own plan. Do not infer shortcuts, skip steps, or pick a different approach because user_message is shorter or the user's original request seems more important.
4. Treat user_message as developer-facing only. It summarizes why the action was blocked; it is not a replacement for agent_message.
5. Run commands from agent_message verbatim when they appear there (bootstrap install/upgrade, cx auth/cx configure, cx ignore-vulnerability, MCP calls). Do not rewrite paths with ${CURSOR_PLUGIN_ROOT} — that variable is empty in the agent shell.
   • When a command is listed per shell (PowerShell: / bash / sh: / cmd.exe: under "Run the line for YOUR shell"), pick the line matching your shell and run that line unchanged. Do not translate a line into another shell's syntax, and do not merge lines. All listed forms are allowed by the gate, so a correct copy is never blocked.
   • When agent_message lists more than one ignore-vulnerability command (multiple findings), run each one as its OWN separate Shell tool call — never join two or more with ;, &&, or || on one line. This matters most on PowerShell with --%: --% makes PowerShell stop parsing for the rest of that entire line, so a ; after it is not treated as a statement separator — it and everything after it (including a second & "cx.exe" --% ... invocation) get swallowed as literal trailing arguments of the FIRST command. Only one process ever runs; cx's own argument parser then chokes on the second command's stray --% token and reports unknown flag: --%, and the second finding is never actually suppressed. The gate's carve-out for this command does not catch it either, since it deliberately never inspects anything after --% (that region isn't shell-executable, so it isn't a security concern — but it also means the gate can't warn you here). One ignore-vulnerability call per Shell tool call, always.
   • A quoted absolute path needs PowerShell's & call operator to execute at all; without it PowerShell just prints the path. Syntax table: skills/cx-cli-setup/references/shells.md.
   • A cx ignore-vulnerability --data <json> command on PowerShell should use --% stop-parsing (preferred form in skills/cx-cli-setup/references/shells.md) — but --% only stops PowerShell from reparsing the remainder; it still reaches cx.exe's own Windows argv parser, which only keeps an embedded " when it's backslash-escaped inside one outer quoted region (--data "{\"FileName\":...}"). A bare, unquoted JSON value gets every " stripped by that parser and sends cx invalid JSON — always wrap it, even under --%. On cmd/bash, double-quote the JSON value and escape every inner " (doubled for cmd, backslash-escaped for bash/sh) — never single-quote it. Cursor's own command-execution layer can reformat a single-quoted argument into a double-quoted one before the real shell runs it, which strips the embedded " around the JSON keys and sends cx invalid JSON. See skills/cx-cli-setup/references/shells.md ("JSON arguments") for the exact per-shell forms.
   • If a command from agent_message still fails, do not improvise an alternate escaping or wrapping — do not backtick-escape it, do not re-wrap it in bash -c '...' or cmd /c "...", and do not retry it with a different quoting style you invent yourself. Those forms are more likely to be blocked by the security gate (its wrapper/chaining checks specifically scrutinize bash -c/cmd /c/backtick-laden commands) than to fix a quoting problem. Stop and report the exact failure to the user instead.
6. Do not bypass the gate. Do not hand-place cx binaries, edit PATH, clear caches, use shell echo/redirect to write blocked files, use shell ! prefix tricks, or retry the same blocked tool call hoping it will pass.
7. Do not deliver blocked content as a workaround. Never paste the blocked code in chat, suggest manual file creation, or tell the user to copy-paste what the hook rejected.
8. Wait for explicit developer direction before writing intentionally vulnerable code that the scanner blocked — the hook deny overrides the original user request until resolved. "The developer originally asked for this vulnerability" is a reason to ask them whether to suppress it, never a reason to suppress it for them without asking.