Cursor 3.11, released on July 10, 2026, introduced three workflow-focused features for Agent users: side chat, conversation search and cloud Agent Hooks. The update targets a specific pain point. When a main Agent is busy with a long task, users can now branch off to ask questions, search prior transcripts or automate checks without stopping the main run.
Side chat opens a parallel thread with inherited context
Side chat is built for moments when the main Agent is in the middle of a long refactor or debugging session and a separate question comes up. Users can start one by typing /side or /btw in the chat box, or by clicking the plus button at the top of the chat panel.
The new chat inherits the context from the main conversation, so there is no need to restate what the Agent was already working on. By default, side chat is limited to reading, searching and answering. It does not modify code unless the user explicitly asks it to do so. Each side chat is also saved as a full Agent conversation that can be revisited later, and its findings can be brought back into the main thread with @.
Cmd+K searches all local transcripts, Cmd+F stays in the current thread
Cursor split transcript search into two levels. Inside the Agents Window, pressing Cmd+K opens the command palette and lets users search the content of Agent transcripts, not just conversation names or PR numbers. According to the source material, Cursor builds a search index locally, which keeps transcript data on the device while still supporting fast lookup across thousands of past chats.
For searches inside the active conversation only, Cmd+F handles the job. It shows a match counter and lets users jump between results while scrolling through long transcripts. One practical note comes right after upgrade: if older chats do not appear immediately, or chat history looks empty, the local index may still be building.
Hooks attach scripts to key Agent events
Hooks are the heavier developer-facing addition in this release. They allow custom scripts to run automatically when an Agent reaches specific lifecycle events. The new 3.11 event points listed in the article are beforeSubmitPrompt, afterAgentResponse, afterAgentThought, subagentStart, subagentStop and stop.
These events cover prompt submission, reply completion, the end of a thinking segment and the lifecycle of subagents. That makes Hooks useful for monitoring execution, inserting control before or after subagents, or building a self-correcting loop. One example in the source describes running tests automatically after an Agent response and sending errors back for another pass.
Where hooks.json lives and what scripts receive
The configuration file is named hooks.json, and its version field must be set to 1. It can be placed at the project level in .cursor/hooks.json, at the user level in ~/.cursor/hooks.json, or at the enterprise level in /etc/cursor/hooks.json. If files exist in those locations, they are executed.
The example provided in the article runs an audit script after file edits and another script when the task stops. Hook scripts receive JSON through standard input, including fields such as conversation_id, generation_id, model and hook_event_name. Event-specific payloads are included as well, such as the prompt text for beforeSubmitPrompt or the reply body for afterAgentResponse.
Only two events can actually block execution
One implementation detail stands out. Not every hook can deny an action. Cursor only checks structured JSON output from scripts for beforeShellExecution and beforeMCPExecution, using it to decide whether to continue.
In those two cases, the permission field can be set to allow, deny or ask. Other hook events may still trigger scripts, record state or launch follow-up actions, but they do not stop the underlying operation.
Cloud Agent limitation affects beforeSubmitPrompt
There is also a cloud-specific limitation. The article notes that beforeSubmitPrompt does not work with cloud Agents because the hook belongs to the very start of the session lifecycle, while the cloud VM is created only after the session begins.
For cloud use, the source recommends relying on hooks tied to tool execution or later runtime stages, including beforeShellExecution, afterFileEdit, subagentStart, subagentStop and stop. Those are described as more reliable in cloud environments.
A full workflow without interrupting the main Agent
The three features are designed to work together. A user can let the main Agent continue a multi-file refactor, open a side chat to inspect where an interface is used, pass the result back into the primary thread with @, and rely on hooks.json to trigger tests once the task ends. If they need to locate what functions were changed, they can search the current transcript with Cmd+F.
The result is a cleaner flow. The main Agent keeps running while investigation, retrieval and automated checks happen around it.