Hook adapters: widen scanned scopes for Cursor (enterprise/project/prompt hooks) and Grok (project hooks, cross-tool discovery)

[Ju571nK]

Motivation

Both hook adapters' core contracts still hold, but each tool grew config scopes Sigil doesn't look at. Verified against https://cursor.com/docs/agent/hooks , https://cursor.com/changelog and the Grok Build changelog (local install 0.2.32; upstream at 0.2.111).

Cursor

Contract from #100/PR #119 is intact: hooks.json with "version": 1, snake_case stdin, {"permission":"allow"|"deny"|"ask"}, failClosed opt-in. What changed:

• Config layers Sigil doesn't scan. Beyond ~/.cursor/hooks.json there are now project .cursor/hooks.json, an enterprise system-wide file (/Library/Application Support/Cursor/hooks.json, /etc/cursor/hooks.json, C:\ProgramData\Cursor\hooks.json), and cloud-distributed Team hooks. Precedence: Enterprise → Team → Project → User. A project-level hook can add behavior Sigil's audit never sees, and a repo-committed hook is itself an untrusted-code surface.
• New hook type "type": "prompt" — an LLM evaluates a natural-language condition and returns {ok, reason}. A static parser expecting command-only entries will mis-read these. It is also a posture finding in its own right: permission decisions delegated to a model.
• New events (beforeSubmitPrompt, afterAgentResponse, stop, subagentStart, preCompact, Tab hooks, …). Additive — Sigil's beforeShellExecution / beforeMCPExecution enforcement points are unchanged — but the parser should recognize the names as valid.
• Cloud agents run repo .cursor/hooks.json command hooks but not user-level hooks, and not beforeMCPExecution. So host-level enforcement via ~/.cursor/hooks.json does not cover Cursor cloud agents. Worth stating plainly in docs rather than implying coverage we don't have.
• Worth re-verifying on 3.11 hardware: forum reports that only deny is reliably enforced and that allow/ask are ignored in favor of the allow-list. Sigil's fail-closed + explicit-allow pattern depends on the deny path, which is the one reported working — but it should be confirmed, not assumed.

Grok Build

Contract from #110 holds — camelCase stdin (toolName/toolInput), {"decision":"deny"}, ~/.grok/hooks/*.json. What changed:

• ~/.grok/hooks/ is now the only always-trusted scope. Project <project>/.grok/hooks/*.json exists and requires explicit trust. Sigil's own hook should stay global (it already does); project hooks are a new scan surface.
• Exit code 2 is now an alternative deny, other non-zero codes fail open. No change needed — emitting explicit JSON deny remains correct — but it is worth a note that a crashing hook fails open.
• Cross-tool config discovery. Grok Build now discovers and executes Claude Code hooks (~/.claude/settings.json always trusted; project .claude/settings.json requires trust) and has per-item toggles for scanning Cursor/Claude skills, rules, agents, and MCP servers. Two consequences: a Sigil hook installed for Claude Code may already enforce inside Grok Build, and conversely a compromised ~/.claude/settings.json now has blast radius across two agents. The compat toggles are themselves a readable posture surface.
• MCP lives in [mcp_servers] in ~/.grok/config.toml / .grok/config.toml — TOML, not JSON. A scan source for the tool-metadata work, needing a different parser.
• /goal long-running autonomous mode exists; like Claude's, it is runtime state with no documented on-disk config — an honest limit, not a gap to close.

Scope

Mechanism only. Adapter/parser scope widening plus docs stating exactly which scopes Sigil covers. Hardware re-verification of the Cursor 3.11 deny path and the Grok project-hook trust flow should precede any behavior change.