Cursor version 3.11 feature tutorial: side chat without interrupting the main window, Cmd+K to revisit past conversations

This article walks you through three new features of Cursor 3.11 all at once: use side chat to ask questions without interrupting the main Agent, use Cmd+K to search through a few thousand old conversations stored locally, and then use Hooks to step in at key points to monitor sub-Agents. Includes a complete runnable hooks.json example, and a “cloud” pitfall you should avoid.
（Background recap: SpaceXAI, Musk’s company, officially released its strongest model “Grok 4.5”! Teaming up with Cursor to aggressively push AI coding agents, with perfect integration with Office office software）
（Additional background: Cursor Mobile launched: a dedicated app that lets you more easily command AI to write code from your phone and supervise the output ）

Table of Contents

Toggle

• Outline of this article
• Side chat keeps the main Agent running—open a new chat that inherits context
• Use Cmd+K to search thousands of old local conversations, use Cmd+F to find the current one
  • Search all old conversations: in the Agents Window press Cmd+K
  • Search the current conversation: press Cmd+F
• Cloud Agent Hooks lets you step in at key nodes, monitor and control sub-Agents
  • How to write hooks.json, and where to put it
  • To block a certain action, only two nodes will acknowledge it
  • Pitfalls for cloud Agents
• How the three features work together
• Appendix: Further resources
• FAQ

The main Agent is running a big refactor, and you suddenly want to check whether some function is called somewhere else. Previously, you could only stop it, switch away, and interrupt the task that was already running. The three features added in Cursor 3.11 (released July 10, 2026)—side chat, conversation search, and cloud Agent Hooks—just happen to solve this “I don’t want to interrupt the main line” problem.

This article assumes you’re already using Cursor’s Agents, and will teach you how to use the three new features at once, with a hooks.json example and a pitfall your cloud Agent will run into.

Outline of this article

• Side chat: keep the main Agent running; open a new chat that inherits context to follow up
• Conversation search: Cmd+K to search thousands of old local conversations; Cmd+F to find the current one
• Cloud Agent Hooks: step in at nodes such as submitting prompts, responses, and when sub-Agents start
• How to串 (chain) the three features together, plus where the cloud hooks can bite you

Side chat so the main Agent doesn’t stop; open a separate chat that inherits context

Side chat solves a very specific scenario: while the main Agent is running a long task, you want to detour and ask a question, but you don’t want to interrupt it.

There are three ways to open a side chat—pick whichever is easiest:

2. Command: type /side or /btw in the chat box
3. Button click: press the + button at the top of the chat panel

The side chat that opens will directly inherit the main conversation’s context, so you don’t need to restate the background—it already knows what you were working on.

The easiest thing to misunderstand here is that side chat’s default behavior is only to do three things: read, search, and answer. It won’t touch your code. Its purpose is to let you follow up, look up information, research an alternative approach, or do a quick sanity-check of a decision before you start making changes—while the main Agent keeps running uninterrupted. If you truly want it to change things, you need to state it explicitly in the conversation.

Each side chat is a complete, long-lasting Agent conversation. It’s not “ask once and discard.” You can come back later and keep asking. When you find a useful conclusion, use @ to bring that side chat back into the main conversation, and the context will reconnect to the main line.

From my own experience, the best use of side chat isn’t asking “What is this?”, but rather: “The main Agent plans to change it like this, but I suspect it will affect X. Can you confirm whether X is relied on elsewhere?” The main line keeps moving, and you verify in parallel—two threads don’t block each other.

Use Cmd+K to search thousands of old local conversations; use Cmd+F to find the current one

If you wanted to find “last week’s Agent conversation—how did it fix that bug,” you basically had to rely on the conversation name or PR number and search slowly. That was painful. Cursor 3.11 adds search into the product, and it comes in two layers.

Search all old conversations: press Cmd+K in the Agents Window

In the Agents Window (Agent conversation view), press Cmd+K to bring up the command palette and directly search the Agent conversation contents (transcript), not just the names and PR numbers. Cursor builds a local search index on your machine, so even if you’ve accumulated a few thousand conversations, searching stays fast.

Because the index is built locally, the content won’t be uploaded to the cloud for searching. This is reassuring for people who care about privacy.

Search the current conversation: press Cmd+F

If you just need to find part of the long conversation you’re currently reading, just use Cmd+F. It will show a match counter (count of matches), letting you jump between matching sections. As you scroll through the long transcript, you can keep searching as well.

One thing to watch for: after upgrading, the index may need a little time to build. If you notice old conversations can’t be found right away, or the chat history looks empty, wait for the index to finish—usually it’s not that data was lost.

Cloud Agent Hooks lets you step in at key nodes to monitor and control sub-Agents

Hooks are the most substantial developer-focused update in this release. They let you attach your own scripts to key nodes in an Agent conversation, and whenever the Agent reaches that node, your script is automatically triggered.

The new nodes added in 3.11 cover several key moments during one Agent conversation cycle:

• beforeSubmitPrompt: you submit the prompt, but before the request is sent to the backend
• afterAgentResponse: after the Agent finishes delivering a reply
• afterAgentThought: after a thinking step (thinking) ends
• subagentStart: before creating a sub-⌃Agent (Task tool)
• subagentStop: after the sub-Agent finishes running
• stop: when the entire Agent loop ends and the task stops

With these nodes, you can do three things: monitor the full execution process, control a sub-Agent before and after it starts, and build an automatic self-correcting loop—e.g., after the Agent finishes a reply, automatically run a test; if it fails, feed the error back so it can fix itself.

How to write hooks.json, and where to put it

Hooks are configured in hooks.json, with version fixed as 1. There are three possible locations: as long as the file exists, it will be executed:

• Project level: /.cursor/hooks.json
• User global: ~/.cursor/hooks.json
• Enterprise level: /etc/cursor/hooks.json

A minimal runnable example that does two things: whenever the Agent edits a file, run an audit script; when the task stops, write a record:

{
  "version": 1,
  "hooks": {
    "afterFileEdit": [
      { "command": "./hooks/audit.sh" }
    ],
    "stop": [
      { "command": "./hooks/on-stop.sh" }
    ]
  }
}

Paths inside command are relative to the location of hooks.json. Your scripts will receive a JSON blob on stdin (standard input). It includes basic fields like conversation_id, generation_id, model, hook_event_name, plus node-specific fields. For example, beforeSubmitPrompt includes the prompt, and afterAgentResponse includes the reply text.

A script that does nothing except confirm it can receive the data looks like this:

#!/bin/bash
cat > /dev/null   # read and discard stdin
exit 0            # report success

To block an action, only two nodes will recognize it

Here’s an easy pitfall: not every hook can intercept actions. Only beforeShellExecution (before running shell commands) and beforeMCPExecution (before calling MCP tools) will check the JSON returned on your stdout to decide whether to allow it through:

{
  "continue": true,
  "permission": "allow",
  "userMessage": "message shown to you",
  "agentMessage": "message shown to the AI"
}

If permission is set to allow, the action proceeds; if deny, it’s blocked; if ask, it prompts you. For other nodes like afterAgentResponse, even if you return permission, they ignore it—they can only observe, log, or trigger other actions, but they can’t block.

Pitfalls for cloud Agent Hooks

If you use Hooks with a cloud Agent, one node will fail outright: beforeSubmitPrompt. The reason is practical: this hook is bound to the session lifecycle at the beginning, but the cloud virtual machine (VM) is created only after the session starts. At the very moment the session begins, the machine doesn’t exist yet—so there’s nothing to run your hook.

From my experience, if you want to use cloud Agents, choose nodes that are bound to “around tool execution,” like beforeShellExecution, afterFileEdit, subagentStart, subagentStop, stop—those are more reliable. Avoid binding to nodes that trigger at the very start of the session.

How the three features work together

The three features are explained separately, but you should try them together to get a feel for how they chain. Here’s a practical scenario:

The main Agent is running a refactor that spans multiple files. You open a side chat (/side) to check “how many places are using this interface,” and the main line keeps running. After you finish checking and determine there’s risk, use @ to bring the side chat conclusion back into the main conversation, so the main Agent handles those places together. Meanwhile, in your hooks.json you’ve attached a stop node: when the refactor finishes, it automatically runs tests. Then you use Cmd+F to jump back into that long conversation and find which functions the Agent said it modified.

After one round, you were never interrupted, and everything you wanted to do got done.

Appendix: Further resources

• Cursor official Changelog: full update notes for each version. The side chat and conversation search in 3.11 are covered there
• Cursor Hooks official documentation: complete reference for all hook nodes, stdin/stdout fields, and the full configuration format
• Cursor Subagents documentation: if you’re using subagentStart/subagentStop nodes, you can start by reading this

FAQ

Q1. Will side chat change my code?
A: By default, no. It only reads, searches, and answers. Its purpose is for you to verify and follow up. If you want it to modify code, you must explicitly say so in the conversation.

Q2. If I close side chat, will it disappear?
A: No. Each side chat is a long-lived complete Agent conversation. You can come back later, continue asking, and you can also bring it back into the main conversation with @.

Q3. Does Cmd+K conversation search search the cloud or local?
A: Local. Cursor builds a search index on your computer. The content is not uploaded for searching, so it can scale all the way to thousands of conversations and stays fast.

Q4. After upgrading, why can’t I find old conversations, or is chat history empty?
A: Most likely the local index is still building. Wait for it to finish—usually it’s not that data was lost.

Q5. What’s the difference between Hooks for cloud Agents vs local?
A: The biggest difference is that beforeSubmitPrompt can’t run in the cloud, because when the session starts, the cloud VM hasn’t been created yet. Nodes tied to “before/after tool execution,” such as beforeShellExecution, afterFileEdit, subagentStart, are more stable in the cloud.

Q6. Where should hooks.json be placed for it to take effect?
A: In the project’s .cursor/hooks.json, the user’s global ~/.cursor/hooks.json, or the enterprise’s /etc/cursor/hooks.json. As long as the file exists in those three locations, it will be executed.

Q7. I want the hook to directly block a dangerous command. Can I do that?
A: Yes, but only beforeShellExecution and beforeMCPExecution listen to the permission you return via stdout. Set permission to deny to block. Other nodes can only observe and trigger actions; they can’t block.