The best agent harness is boring at the boundary.

Video caption

The best agent harness is boring at the boundary. The runtime is part of the control. A path hook is one interception surface. #EricFieldNotes

Full written post / accessibility read

Give an agent room to design inside a worktree. A pre-tool script can check a file operation it actually understands. Arbitrary shell or MCP calls need denial or an OS and network sandbox that limits their effects. Post-action receipts and a separately owned CI gate then test the exact artifact. Markdown rules alone cannot enforce that chain.

Cursor documents preToolUse and file and shell events. Unexpected nonzero hook exits can allow an action by default. Project hooks reach cloud agents, but user-local hooks do not, and cloud beforeMCPExecution is unavailable. Map actual coverage and failures for each runtime instead of treating one hook file as universal enforcement.

In a disposable repo, request the same forbidden write through the file tool, shell and MCP. If a route cannot be parsed and constrained, deny it or put it inside a sandbox that removes the forbidden permission. Inspect actual file and network state after every attempt. Then make a protected acceptance mutant turn external CI red.

My rule: use hooks for covered operations and receipts, deny or sandbox opaque routes, and keep product acceptance in CI that the worker cannot edit or impersonate. Do this because a model may choose another tool, and a hook may fail open; independent service permissions and release checks bound the consequence.

#EricFieldNotes

Four-beat scene transcript

1. The best agent harness is boring at the boundary.

Give an agent room to design inside a worktree. A pre-tool script can check a file operation it actually understands. Arbitrary shell or MCP calls need denial or an OS and network sandbox that limits their effects. Post-action receipts and a separately owned CI gate then test the exact artifact. Markdown rules alone cannot enforce that chain.

Visual: Creative code needs a bounded effect surface.

2. Know which hook can fail open.

Cursor documents preToolUse and file and shell events. Unexpected nonzero hook exits can allow an action by default. Project hooks reach cloud agents, but user-local hooks do not, and cloud beforeMCPExecution is unavailable. Map actual coverage and failures for each runtime instead of treating one hook file as universal enforcement.

Visual: The runtime is part of the control.

3. Run the deny canary.

In a disposable repo, request the same forbidden write through the file tool, shell and MCP. If a route cannot be parsed and constrained, deny it or put it inside a sandbox that removes the forbidden permission. Inspect actual file and network state after every attempt. Then make a protected acceptance mutant turn external CI red.

Visual: Observe the filesystem and network effect.

4. Keep authority outside the worker.

My rule: use hooks for covered operations and receipts, deny or sandbox opaque routes, and keep product acceptance in CI that the worker cannot edit or impersonate. Do this because a model may choose another tool, and a hook may fail open; independent service permissions and release checks bound the consequence.

Visual: A path hook is one interception surface.

Research and claim limits

• Cursor hooks documentation (S04)
• GitHub Docs: ruleset required status checks (S146)

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