Cursor 3.11 Cloud Hooks — Don't Trust Them for Governance

Cursor 3.11 dropped on July 10, 2026 with a promise that matters to every team running cloud agent fleets: five new lifecycle hooks that let you intercept, audit, and gate agent behavior at the repository level via .cursor/hooks.json. The pitch was “predictable and configurable at org scale.” The reality, three weeks in, is that the hooks most critical for compliance — output screening, prompt-level PII filtering, agent-completion audits — are precisely the ones that do not work reliably. I would not build a governance layer on top of them today.

TL;DR

• What: Cursor 3.11 added five cloud agent hooks: beforeSubmitPrompt, afterAgentResponse, afterAgentThought, subagentStart, stop
• Broken: afterAgentResponse and stop don’t reliably fire in cloud VMs; beforeSubmitPrompt fires but silently strips prompt modifications before they reach the model
• Working: File/tool hooks (beforeShellExecution, afterFileEdit) and afterAgentThought run reliably; side chats and transcript search are the real wins in this release
• Action: Treat cloud agent hooks as preview-grade until at least 3.12 ships and the forum bug threads go quiet

Cursor 3.11 Cloud Agent Hooks — What Happened

The 3.11 release introduced five new hook lifecycle events for cloud agents: beforeSubmitPrompt, afterAgentResponse, afterAgentThought, subagentStart, and stop. All five are configurable via a repo-level .cursor/hooks.json file that applies automatically to every cloud agent run against that repository — no per-agent setup required. The design is clean: drop a JSON config in your repo, define scripts for the events you care about, and every agent session picks them up.

Alongside hooks, 3.11 shipped side chats (triggered via /side, /btw, or the plus button), agent transcript search backed by a local index, and redesigned project, repo, and branch pickers scoped by location. These features work. The hooks, for cloud agents specifically, do not — at least not the ones that matter most.

Community bug reports on Cursor’s forum surfaced within days of release. The problems break down into three distinct failures:

afterAgentResponse and stop do not reliably fire in cloud agent VMs. These are the hooks you would use for output screening — checking what the agent produced before it reaches the user or downstream systems — and for agent-completion audits. Cursor has acknowledged the bug. No patch date is confirmed.

beforeSubmitPrompt fires and returns a modified prompt, but the modification is silently stripped. The model receives the original, unmodified prompt. This is arguably the worst of the three bugs because it creates a false sense of security. Your PII-stripping hook runs, returns a clean prompt, and the dirty prompt goes to the model anyway. Nothing in the UI or logs tells you this happened.

MCP hooks are cloud-dead by design. beforeMCPExecution and afterMCPExecution do not fire in cloud agents at all. Cursor’s documentation describes them as “deferred for read-only environments.” If your policy layer screens MCP tool calls, it only protects local sessions today. This is not a bug — it is a known limitation — but the changelog does not make it obvious.

The beforeSubmitPrompt bug is particularly dangerous because it fails silently. Your hook executes, returns a modified prompt, and reports success. The model never sees the modification. Any PII filtering or prompt-injection guard built on this hook is inoperative without surfacing an error.

Why This Matters

The hook system was Cursor’s answer to a real and growing problem: how do you enforce governance policies across a fleet of cloud agents? When your org has fifty developers spawning background agents that read codebases, execute shell commands, and call external tools, you need interception points. Hooks were supposed to be those interception points.

The architecture is sound in principle. A repo-level .cursor/hooks.json that auto-applies to every agent session is the right abstraction — it follows the code, not the developer’s local config, which means policy travels with the repository. For teams subject to SOC 2, HIPAA, or internal data-handling policies, this is exactly the mechanism they need. The problem is execution, not design.

What makes the current state especially frustrating is the asymmetry between what works and what does not. File and tool hooks — beforeShellExecution, afterFileEdit, subagentStart, and afterAgentThought — run reliably on cloud agents. These are useful for guardrailing destructive actions: blocking rm -rf, gating database migrations, logging tool invocations. But they operate at the action layer, not the prompt or response layer. The hooks that would let you screen what goes INTO the model (beforeSubmitPrompt) and what comes OUT (afterAgentResponse) are the broken ones. That is not a random distribution of bugs. It is the governance-critical path that fails.

There is a platform-specific failure mode compounding this. A bug filed on Cursor’s forum on July 27, 2026 shows that on Windows, the JSON payload delivered to hook scripts via stdin includes a UTF-8 BOM (\uFEFF). Any hook that does a standard JSON.parse() on the raw input throws. If the script handles the parse error defensively — a try/catch that returns an empty object — the security guard silently degrades to allow-everything. No error surfaces anywhere. The hook appears to run; it just does nothing.

If you are running hooks on Windows today, strip the BOM before parsing: input.replace(/^\uFEFF/, ''). This is a workaround, not a fix — Cursor should not be emitting BOMs in structured payloads.

Compare this to how Cursor has positioned itself over the past few months. Cursor’s 3.0 release pitched the platform as enterprise-ready orchestration infrastructure. The agent setup guide walks teams through configuring multi-agent workflows with the assumption that policy hooks will enforce constraints. That assumption is now invalid for cloud deployments. And as I wrote when covering the SDK and infrastructure lock-in risks, building your compliance layer on top of a single vendor’s extension points creates exactly this kind of fragility — you are one broken release away from an unguarded fleet.

The Take

Treat cloud agent hooks as a feature in preview, not production infrastructure, until 3.12 ships and the forum bug threads close. The design is right. The implementation is not ready. If you are evaluating Cursor 3.11 for an org-wide rollout, here is what you can rely on today: file and tool hooks work, side chats are genuinely useful for managing parallel agent conversations, and transcript search across local history is a real workflow improvement. Those are shippable features.

The hooks that matter for compliance — output screening, prompt modification, agent-completion audits — are not shippable. Do not let the changelog convince you otherwise. A hook that fires but silently ignores your modifications is worse than no hook at all, because it creates audit trails that look correct while enforcing nothing. If your compliance team asks whether agent outputs are screened, the honest answer today is: only in local sessions, and only for file and tool operations.

Build your governance layer on what works. Wait for the rest.