Product · @synoi/guard
Pre-releaseYou're running Claude Code or Cursor.
Know what a tool call will do before it does it.
@synoi/guard is a pre-execution hook that sits in front of your coding agent. Each hooked tool call, a shell command, a file write, an MCP tool, routes through your SynOI risk policy first: allow, deny, or require your approval, with a signed Decision Receipt either way. Fail-closed by default: if the policy check cannot complete, the call is blocked, not waved through.
Pre-release: @synoi/guard is not yet published to npm. The commands below show the install shape planned for launch, not something you can run today.
Why this exists
A settings toggle is not a governance boundary.
In July 2026, a widely used AI coding CLI (not from Anthropic, not from SynOI) was found uploading entire local repositories, committed secrets included, to a cloud storage bucket during normal use. Its own privacy toggle had no effect on the upload. We wrote up the wire-level details at /breaches/grok-build-cli-2026.
To be direct: @synoi/guard does not target that specific tool, and nothing here would have caught that specific incident. It gates Claude Code and Cursor, not that vendor's CLI. What the incident shows is a pattern, not a one-off bug: an agent's own settings are not a governance boundary, because the agent (and its host application) is the thing deciding whether to honor them.
The countermeasure class @synoi/guard belongs to is a pre-execution gate that sits outside the agent, makes the allow, deny, or ask decision itself, and produces a signed receipt of what happened, so the record does not depend on the agent's own self-reporting.
Capability coverage
Read this before you rely on either host.
Claude Code and Cursor expose different hook surfaces. @synoi/guard is honest about the difference rather than papering over it: Claude Code is the primary, verified surface; Cursor is beta, with three specific gaps documented below.
| Surface | Claude Code | Cursor |
|---|---|---|
| Status | Primary, verified | Beta |
| Shell / bash | Pre-execution block via PreToolUse | Pre-execution block via beforeShellExecution |
| File write / edit | Pre-execution block via PreToolUse | No pre-execution block. Cursor exposes only afterFileEdit: an audit after the write, not a way to stop it |
| File read | Pre-execution block via PreToolUse | beforeReadFile can only allow or deny; it cannot prompt, so a require-approval verdict degrades to allow-with-audit |
| MCP tools | Pre-execution block via PreToolUse | beforeMCPExecution, local desktop sessions only. Cursor's cloud and background agents are not hooked at all |
Cursor Hooks are a beta feature of Cursor itself and its schema may still change. If your workflow depends on blocking file writes or governing cloud agent runs, Claude Code is the surface that covers it today; Cursor does not yet have an equivalent hook for either.
2-minute quickstart
Available at launchThe shape of the install we're targeting.
@synoi/guard has not shipped yet. The steps below show the planned install path so you can see where this is headed; they are not runnable against a published package today. Join early access and we'll tell you the moment they are.
Planned install · available at launch, not runnable today
# 1. Run a local gateway (no license needed for local-only policy evaluation) npx @synoi/gateway-lite # 2. Install the guard npm i -g @synoi/guard # 3. Register the hook for your host synoi-guard install --host claude # (swap --host cursor for Cursor; you can run both) # 4. Point the hook at your local gateway export SYNOI_GATEWAY_URL=http://localhost:3000 # The next tool call your host makes in this project goes through # the local gateway's risk policy first.
How it works
One decision, one path, whichever host you run.
Before the tool call runs
Both Claude Code and Cursor let you register a command that runs before a tool executes. The host pipes a JSON payload to that command's stdin; the command writes back a verdict that can allow, deny, or force an approval prompt.
One governance path, not three
The decision is made once, through the same decide() call the SDK and the OpenClaw guard use. This guard, the OpenClaw guard, and a direct SDK integration all share one risk policy instead of three separate ones.
Fail-closed by default
If the license is missing, the gateway is unreachable, or it returns an error or an unrecognized verdict, strict mode blocks the call. Permissive (fail-open) mode is an explicit opt-in, not the default.
Additive on allow
On an allow verdict, the guard stays silent on Claude Code by default, so your existing permission prompts still apply. It only ever tightens what your host already asks; auto-approve is an opt-in setting.
Be honest about the boundary
Registering the hook is opt-in. That is worth saying plainly.
A hook the runtime invokes once registered is a stronger enforcement point than a voluntary SDK wrapper, because the agent cannot route around it after that. But registering the hook in the first place is still opt-in at the operator's own configuration, so this is not a non-bypassable control on an adversarial host. The durable governance layer is credential custody on the brokered path plus the identity-bound Decision Receipt; @synoi/guard is a convenient on-ramp to that path, not the boundary itself.
Gate the tool calls your coding agent makes.
@synoi/guard is pre-release. Join early access and we'll reach out when it's ready to install against Claude Code or Cursor.