How it works

Approvals & alerts

Some actions shouldn't be auto-allowed or auto-blocked — they need a human. gmonk can hold an action mid-flight until someone decides, and notify you the moment it happens.

Holds

A guard rule or gate outcome of require_approval is a real hold: the agent's call blocks until a human approves (→ executes), denies (→ refused), or it times out (→ expired, and can't be retro-approved). Decisions are atomic. Enforced at the SQL gateway, the object gateway, and the MCP proxy.

bash

gmonk approvals          # list pending holds
gmonk approve <id>       # approve → the held action executes
gmonk deny <id>          # deny → the action is refused

The same approve/deny is available as a banner in the review UI. GMONK_APPROVAL_TIMEOUT_MS (default 5 min) bounds how long a hold waits.

Alerts

gmonk POSTs alerts to a webhook (Slack-compatible payload) on the events you choose. It's best-effort and timeout-bounded — it never throws or blocks the agent.

bash

GMONK_ALERT_WEBHOOK=https://hooks.slack.com/services/…
GMONK_ALERT_EVENTS=require_approval,block,recoverability_degraded,recoverability_lost,out_of_band

Events: require_approval, block, warn, approved, denied, recoverability_degraded, recoverability_lost, out_of_band (a write that bypassed the gateway but was still caught on a protected table).

Interactive Slack approvals

Approve or deny a held action from Slack buttons — no context switch. Two transports:

Socket Mode (recommended) — an outbound WebSocket, no inbound port. Set GMONK_SLACK_APP_TOKEN and run gmonk slack-listen.
HTTP Request-URL — a signature-gated POST /slack/interactions endpoint, via GMONK_SLACK_SIGNING_SECRET.

← Recovery Deployment & security →