Corrupt the hook response and press run.

Video caption

Corrupt the hook response and press run. Another route may never call that script. The target readback is the verdict. #EricFieldNotes

Full written post / accessibility read

You have a pre-tool script that normally denies a forbidden deployment. In a disposable workspace, make it emit malformed JSON, exceed its timeout and exit unexpectedly. The canary deployment increments a target counter if it runs. What actually happens?

First prove an authorized canary increments the counter. Then attempt the denied request locally, in an available cloud agent, through a delegate and after resume. For each route, capture hook and tool invocation plus the external counter. One green row says nothing about an untested route.

Where a product's hook error may continue, place the hard limit at a lower service boundary with a narrow credential. Have the harness report the hook failure and keep the task pending. Test that the target remains unchanged even if the agent keeps talking.

Ship the hook only with its failure-injection results, service scope and rollback owner. Do this because a model can narrate compliance after a broken gate; the external state tells you whether the forbidden operation completed.

#EricFieldNotes

Four-beat scene transcript

1. Corrupt the hook response and press run.

You have a pre-tool script that normally denies a forbidden deployment. In a disposable workspace, make it emit malformed JSON, exceed its timeout and exit unexpectedly. The canary deployment increments a target counter if it runs. What actually happens?

Visual: Happy-path demos hide the default behavior.

2. A blocked log can be a false comfort.

First prove an authorized canary increments the counter. Then attempt the denied request locally, in an available cloud agent, through a delegate and after resume. For each route, capture hook and tool invocation plus the external counter. One green row says nothing about an untested route.

Visual: Another route may never call that script.

3. Make failure behavior explicit.

Where a product's hook error may continue, place the hard limit at a lower service boundary with a narrow credential. Have the harness report the hook failure and keep the task pending. Test that the target remains unchanged even if the agent keeps talking.

Visual: Deny, alert or unavailable—never ambiguous success.

4. Prove the effect was blocked.

Ship the hook only with its failure-injection results, service scope and rollback owner. Do this because a model can narrate compliance after a broken gate; the external state tells you whether the forbidden operation completed.

Visual: The target readback is the verdict.

Research and claim limits

• Cursor hooks documentation (S04)
• Claude Code hooks reference (S45)
• Codex hooks reference (S44)

The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.