caruso 0.6.2 → 0.7.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/CHANGELOG.md +41 -0
- data/impl.md +111 -0
- data/lib/caruso/adapter.rb +16 -96
- data/lib/caruso/adapters/base.rb +102 -0
- data/lib/caruso/adapters/command_adapter.rb +88 -0
- data/lib/caruso/adapters/dispatcher.rb +83 -0
- data/lib/caruso/adapters/hook_adapter.rb +222 -0
- data/lib/caruso/adapters/markdown_adapter.rb +23 -0
- data/lib/caruso/adapters/skill_adapter.rb +87 -0
- data/lib/caruso/cli.rb +22 -6
- data/lib/caruso/config_manager.rb +30 -28
- data/lib/caruso/fetcher.rb +137 -29
- data/lib/caruso/remover.rb +73 -13
- data/lib/caruso/version.rb +1 -1
- data/package-lock.json +6 -0
- data/reference/claude_code_create_marketplaces.md +511 -0
- data/reference/claude_code_hooks.md +1137 -0
- data/reference/claude_code_plugins.md +769 -0
- data/reference/claude_code_slash_commands.md +515 -0
- data/reference/cursor_commands.md +90 -0
- data/reference/cursor_hooks.md +467 -0
- data/reference/cursor_modes.md +105 -0
- data/reference/cursor_rules.md +246 -0
- data/reference/steering_docs.md +57 -0
- data/tasks.md +22 -0
- metadata +20 -3
- data/reference/plugins_reference.md +0 -376
- /data/reference/{marketplace.md → claude_code_marketplaces.md} +0 -0
|
@@ -0,0 +1,467 @@
|
|
|
1
|
+
# Hooks
|
|
2
|
+
|
|
3
|
+
Hooks let you observe, control, and extend the agent loop using custom scripts. Hooks are spawned processes that communicate over stdio using JSON in both directions. They run before or after defined stages of the agent loop and can observe, block, or modify behavior.
|
|
4
|
+
|
|
5
|
+
With hooks, you can:
|
|
6
|
+
|
|
7
|
+
- Run formatters after edits
|
|
8
|
+
- Add analytics for events
|
|
9
|
+
- Scan for PII or secrets
|
|
10
|
+
- Gate risky operations (e.g., SQL writes)
|
|
11
|
+
|
|
12
|
+
Looking for ready-to-use integrations? See [Partner Integrations](#partner-integrations) for security, governance, and secrets management solutions from our ecosystem partners.
|
|
13
|
+
|
|
14
|
+
## Agent and Tab Support
|
|
15
|
+
|
|
16
|
+
Hooks work with both **Cursor Agent** (Cmd+K/Agent Chat) and **Cursor Tab** (inline completions), but they use different hook events:
|
|
17
|
+
|
|
18
|
+
**Agent (Cmd+K/Agent Chat)** uses the standard hooks:
|
|
19
|
+
|
|
20
|
+
- `beforeShellExecution` / `afterShellExecution` - Control shell commands
|
|
21
|
+
- `beforeMCPExecution` / `afterMCPExecution` - Control MCP tool usage
|
|
22
|
+
- `beforeReadFile` / `afterFileEdit` - Control file access and edits
|
|
23
|
+
- `beforeSubmitPrompt` - Validate prompts before submission
|
|
24
|
+
- `stop` - Handle agent completion
|
|
25
|
+
- `afterAgentResponse` / `afterAgentThought` - Track agent responses
|
|
26
|
+
|
|
27
|
+
**Tab (inline completions)** uses specialized hooks:
|
|
28
|
+
|
|
29
|
+
- `beforeTabFileRead` - Control file access for Tab completions
|
|
30
|
+
- `afterTabFileEdit` - Post-process Tab edits
|
|
31
|
+
|
|
32
|
+
These separate hooks allow different policies for autonomous Tab operations versus user-directed Agent operations.
|
|
33
|
+
|
|
34
|
+
## Quickstart
|
|
35
|
+
|
|
36
|
+
Create a `hooks.json` file. You can create it at the project level (`<project>/.cursor/hooks.json`) or in your home directory (`~/.cursor/hooks.json`). Project-level hooks apply only to that specific project, while home directory hooks apply globally.
|
|
37
|
+
|
|
38
|
+
```
|
|
39
|
+
{
|
|
40
|
+
"version": 1,
|
|
41
|
+
"hooks": {
|
|
42
|
+
"afterFileEdit": [{ "command": "./hooks/format.sh" }]
|
|
43
|
+
}
|
|
44
|
+
}
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
Create your hook script at `~/.cursor/hooks/format.sh`:
|
|
48
|
+
|
|
49
|
+
```
|
|
50
|
+
#!/bin/bash
|
|
51
|
+
# Read input, do something, exit 0
|
|
52
|
+
cat > /dev/null
|
|
53
|
+
exit 0
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
Make it executable:
|
|
57
|
+
|
|
58
|
+
```
|
|
59
|
+
chmod +x ~/.cursor/hooks/format.sh
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
Restart Cursor. Your hook now runs after every file edit.
|
|
63
|
+
|
|
64
|
+
## Examples
|
|
65
|
+
|
|
66
|
+
hooks.jsonaudit.shblock-git.sh```
|
|
67
|
+
{
|
|
68
|
+
"version": 1,
|
|
69
|
+
"hooks": {
|
|
70
|
+
"beforeShellExecution": [
|
|
71
|
+
{
|
|
72
|
+
"command": "./hooks/audit.sh"
|
|
73
|
+
},
|
|
74
|
+
{
|
|
75
|
+
"command": "./hooks/block-git.sh"
|
|
76
|
+
}
|
|
77
|
+
],
|
|
78
|
+
"beforeMCPExecution": [
|
|
79
|
+
{
|
|
80
|
+
"command": "./hooks/audit.sh"
|
|
81
|
+
}
|
|
82
|
+
],
|
|
83
|
+
"afterShellExecution": [
|
|
84
|
+
{
|
|
85
|
+
"command": "./hooks/audit.sh"
|
|
86
|
+
}
|
|
87
|
+
],
|
|
88
|
+
"afterMCPExecution": [
|
|
89
|
+
{
|
|
90
|
+
"command": "./hooks/audit.sh"
|
|
91
|
+
}
|
|
92
|
+
],
|
|
93
|
+
"afterFileEdit": [
|
|
94
|
+
{
|
|
95
|
+
"command": "./hooks/audit.sh"
|
|
96
|
+
}
|
|
97
|
+
],
|
|
98
|
+
"beforeSubmitPrompt": [
|
|
99
|
+
{
|
|
100
|
+
"command": "./hooks/audit.sh"
|
|
101
|
+
}
|
|
102
|
+
],
|
|
103
|
+
"stop": [
|
|
104
|
+
{
|
|
105
|
+
"command": "./hooks/audit.sh"
|
|
106
|
+
}
|
|
107
|
+
],
|
|
108
|
+
"beforeTabFileRead": [
|
|
109
|
+
{
|
|
110
|
+
"command": "./hooks/redact-secrets-tab.sh"
|
|
111
|
+
}
|
|
112
|
+
],
|
|
113
|
+
"afterTabFileEdit": [
|
|
114
|
+
{
|
|
115
|
+
"command": "./hooks/format-tab.sh"
|
|
116
|
+
}
|
|
117
|
+
]
|
|
118
|
+
}
|
|
119
|
+
}
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
## Partner Integrations
|
|
123
|
+
|
|
124
|
+
We partner with ecosystem vendors who have built hooks support with Cursor. These integrations cover security scanning, governance, secrets management, and more.
|
|
125
|
+
|
|
126
|
+
### MCP governance and visibility
|
|
127
|
+
|
|
128
|
+
PartnerDescription[MintMCP](https://www.mintmcp.com/blog/mcp-governance-cursor-hooks)Build a complete inventory of MCP servers, monitor tool usage patterns, and scan responses for sensitive data before it reaches the AI model.[Oasis Security](https://www.oasis.security/blog/cursor-oasis-governing-agentic-access)Enforce least-privilege policies on AI agent actions and maintain full audit trails across enterprise systems.[Runlayer](https://www.runlayer.com/blog/cursor-hooks)Wrap MCP tools and integrate with their MCP broker for centralized control and visibility over agent-to-tool interactions.
|
|
129
|
+
### Code security and best practices
|
|
130
|
+
|
|
131
|
+
PartnerDescription[Corridor](https://corridor.dev/blog/corridor-cursor-hooks/)Get real-time feedback on code implementation and security design decisions as code is being written.[Semgrep](https://semgrep.dev/blog/2025/cursor-hooks-mcp-server)Automatically scan AI-generated code for vulnerabilities with real-time feedback to regenerate code until security issues are resolved.
|
|
132
|
+
### Dependency security
|
|
133
|
+
|
|
134
|
+
PartnerDescription[Endor Labs](https://www.endorlabs.com/learn/bringing-malware-detection-into-ai-coding-workflows-with-cursor-hooks)Intercept package installations and scan for malicious dependencies, preventing supply chain attacks before they enter your codebase.
|
|
135
|
+
### Agent security and safety
|
|
136
|
+
|
|
137
|
+
PartnerDescription[Snyk](https://snyk.io/blog/evo-agent-guard-cursor-integration/)Review agent actions in real-time with Evo Agent Guard, detecting and preventing issues like prompt injection and dangerous tool calls.
|
|
138
|
+
### Secrets management
|
|
139
|
+
|
|
140
|
+
PartnerDescription[1Password](https://marketplace.1password.com/integration/cursor-hooks)Validate that environment files from 1Password Environments are properly mounted before shell commands execute, enabling just-in-time secrets access without writing credentials to disk.
|
|
141
|
+
For more details about our hooks partners, see the [Hooks for security and platform teams](/blog/hooks-partners) blog post.
|
|
142
|
+
|
|
143
|
+
## Configuration
|
|
144
|
+
|
|
145
|
+
Define hooks in a `hooks.json` file. Configuration can exist at multiple levels; higher-priority sources override lower ones:
|
|
146
|
+
|
|
147
|
+
```
|
|
148
|
+
~/.cursor/
|
|
149
|
+
├── hooks.json
|
|
150
|
+
└── hooks/
|
|
151
|
+
├── audit.sh
|
|
152
|
+
└── block-git.sh
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
- **Global** (Enterprise-managed):
|
|
156
|
+
- macOS: `/Library/Application Support/Cursor/hooks.json`
|
|
157
|
+
- Linux/WSL: `/etc/cursor/hooks.json`
|
|
158
|
+
- Windows: `C:\\ProgramData\\Cursor\\hooks.json`
|
|
159
|
+
- **Project Directory** (Project-specific):
|
|
160
|
+
- `<project-root>/.cursor/hooks.json`
|
|
161
|
+
- Project hooks run in any trusted workspace and are checked into version control with your project
|
|
162
|
+
- **Home Directory** (User-specific):
|
|
163
|
+
- `~/.cursor/hooks.json`
|
|
164
|
+
|
|
165
|
+
Priority order (highest to lowest): Enterprise → Project → User
|
|
166
|
+
|
|
167
|
+
The `hooks` object maps hook names to arrays of hook definitions. Each definition currently supports a `command` property that can be a shell string, an absolute path, or a path relative to the `hooks.json` file.
|
|
168
|
+
|
|
169
|
+
### Configuration file
|
|
170
|
+
|
|
171
|
+
```
|
|
172
|
+
{
|
|
173
|
+
"version": 1,
|
|
174
|
+
"hooks": {
|
|
175
|
+
"beforeShellExecution": [{ "command": "./script.sh" }],
|
|
176
|
+
"afterShellExecution": [{ "command": "./script.sh" }],
|
|
177
|
+
"afterMCPExecution": [{ "command": "./script.sh" }],
|
|
178
|
+
"afterFileEdit": [{ "command": "./format.sh" }],
|
|
179
|
+
"beforeTabFileRead": [{ "command": "./redact-secrets-tab.sh" }],
|
|
180
|
+
"afterTabFileEdit": [{ "command": "./format-tab.sh" }]
|
|
181
|
+
}
|
|
182
|
+
}
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
The Agent hooks (`beforeShellExecution`, `afterShellExecution`, `beforeMCPExecution`, `afterMCPExecution`, `beforeReadFile`, `afterFileEdit`, `beforeSubmitPrompt`, `stop`, `afterAgentResponse`, `afterAgentThought`) apply to Cmd+K and Agent Chat operations. The Tab hooks (`beforeTabFileRead`, `afterTabFileEdit`) apply specifically to inline Tab completions.
|
|
186
|
+
|
|
187
|
+
## Team Distribution
|
|
188
|
+
|
|
189
|
+
Hooks can be distributed to team members using project hooks (via version control), MDM tools, or Cursor's cloud distribution system.
|
|
190
|
+
|
|
191
|
+
### Project Hooks (Version Control)
|
|
192
|
+
|
|
193
|
+
Project hooks are the simplest way to share hooks with your team. Place a `hooks.json` file at `<project-root>/.cursor/hooks.json` and commit it to your repository. When team members open the project in a trusted workspace, Cursor automatically loads and runs the project hooks.
|
|
194
|
+
|
|
195
|
+
Project hooks:
|
|
196
|
+
|
|
197
|
+
- Are stored in version control alongside your code
|
|
198
|
+
- Automatically load for all team members in trusted workspaces
|
|
199
|
+
- Can be project-specific (e.g., enforce formatting standards for a particular codebase)
|
|
200
|
+
- Require the workspace to be trusted to run (for security)
|
|
201
|
+
|
|
202
|
+
### MDM Distribution
|
|
203
|
+
|
|
204
|
+
Distribute hooks across your organization using Mobile Device Management (MDM) tools. Place the `hooks.json` file and hook scripts in the target directories on each machine.
|
|
205
|
+
|
|
206
|
+
**User home directory** (per-user distribution):
|
|
207
|
+
|
|
208
|
+
- `~/.cursor/hooks.json`
|
|
209
|
+
- `~/.cursor/hooks/` (for hook scripts)
|
|
210
|
+
|
|
211
|
+
**Global directories** (system-wide distribution):
|
|
212
|
+
|
|
213
|
+
- macOS: `/Library/Application Support/Cursor/hooks.json`
|
|
214
|
+
- Linux/WSL: `/etc/cursor/hooks.json`
|
|
215
|
+
- Windows: `C:\\ProgramData\\Cursor\\hooks.json`
|
|
216
|
+
|
|
217
|
+
Note: MDM-based distribution is fully managed by your organization. Cursor does not deploy or manage files through your MDM solution. Ensure your internal IT or security team handles configuration, deployment, and updates in accordance with your organization's policies.
|
|
218
|
+
|
|
219
|
+
### Cloud Distribution (Enterprise Only)
|
|
220
|
+
|
|
221
|
+
Enterprise teams can use Cursor's native cloud distribution to automatically sync hooks to all team members. Configure hooks in the [web dashboard](https://cursor.com/dashboard?tab=team-content§ion=hooks). Cursor automatically delivers configured hooks to all client machines when team members log in.
|
|
222
|
+
|
|
223
|
+
Cloud distribution provides:
|
|
224
|
+
|
|
225
|
+
- Automatic synchronization to all team members (every thirty minutes)
|
|
226
|
+
- Operating system targeting for platform-specific hooks
|
|
227
|
+
- Centralized management through the dashboard
|
|
228
|
+
|
|
229
|
+
Enterprise administrators can create, edit, and manage team hooks from the dashboard without requiring access to individual machines.
|
|
230
|
+
|
|
231
|
+
## Reference
|
|
232
|
+
|
|
233
|
+
### Common schema
|
|
234
|
+
|
|
235
|
+
#### Input (all hooks)
|
|
236
|
+
|
|
237
|
+
All hooks receive a base set of fields in addition to their hook-specific fields:
|
|
238
|
+
|
|
239
|
+
```
|
|
240
|
+
{
|
|
241
|
+
"conversation_id": "string",
|
|
242
|
+
"generation_id": "string",
|
|
243
|
+
"model": "string",
|
|
244
|
+
"hook_event_name": "string",
|
|
245
|
+
"cursor_version": "string",
|
|
246
|
+
"workspace_roots": ["<path>"],
|
|
247
|
+
"user_email": "string | null"
|
|
248
|
+
}
|
|
249
|
+
```
|
|
250
|
+
|
|
251
|
+
FieldTypeDescription`conversation_id`stringStable ID of the conversation across many turns`generation_id`stringThe current generation that changes with every user message`model`stringThe model configured for the composer that triggered the hook`hook_event_name`stringWhich hook is being run`cursor_version`stringCursor application version (e.g. "1.7.2")`workspace_roots`string[]The list of root folders in the workspace (normally just one, but multiroot workspaces can have multiple)`user_email`string | nullEmail address of the authenticated user, if available
|
|
252
|
+
### Hook events
|
|
253
|
+
|
|
254
|
+
#### beforeShellExecution / beforeMCPExecution
|
|
255
|
+
|
|
256
|
+
Called before any shell command or MCP tool is executed. Return a permission decision.
|
|
257
|
+
|
|
258
|
+
```
|
|
259
|
+
// beforeShellExecution input
|
|
260
|
+
{
|
|
261
|
+
"command": "<full terminal command>",
|
|
262
|
+
"cwd": "<current working directory>"
|
|
263
|
+
}
|
|
264
|
+
|
|
265
|
+
// beforeMCPExecution input
|
|
266
|
+
{
|
|
267
|
+
"tool_name": "<tool name>",
|
|
268
|
+
"tool_input": "<json params>"
|
|
269
|
+
}
|
|
270
|
+
// Plus either:
|
|
271
|
+
{ "url": "<server url>" }
|
|
272
|
+
// Or:
|
|
273
|
+
{ "command": "<command string>" }
|
|
274
|
+
|
|
275
|
+
// Output
|
|
276
|
+
{
|
|
277
|
+
"permission": "allow" | "deny" | "ask",
|
|
278
|
+
"user_message": "<message shown in client>",
|
|
279
|
+
"agent_message": "<message sent to agent>"
|
|
280
|
+
}
|
|
281
|
+
```
|
|
282
|
+
|
|
283
|
+
#### afterShellExecution
|
|
284
|
+
|
|
285
|
+
Fires after a shell command executes; useful for auditing or collecting metrics from command output.
|
|
286
|
+
|
|
287
|
+
```
|
|
288
|
+
// Input
|
|
289
|
+
{
|
|
290
|
+
"command": "<full terminal command>",
|
|
291
|
+
"output": "<full terminal output>",
|
|
292
|
+
"duration": 1234
|
|
293
|
+
}
|
|
294
|
+
```
|
|
295
|
+
|
|
296
|
+
FieldTypeDescription`command`stringThe full terminal command that was executed`output`stringFull output captured from the terminal`duration`numberDuration in milliseconds spent executing the shell command (excludes approval wait time)
|
|
297
|
+
#### afterMCPExecution
|
|
298
|
+
|
|
299
|
+
Fires after an MCP tool executes; includes the tool's input parameters and full JSON result.
|
|
300
|
+
|
|
301
|
+
```
|
|
302
|
+
// Input
|
|
303
|
+
{
|
|
304
|
+
"tool_name": "<tool name>",
|
|
305
|
+
"tool_input": "<json params>",
|
|
306
|
+
"result_json": "<tool result json>",
|
|
307
|
+
"duration": 1234
|
|
308
|
+
}
|
|
309
|
+
```
|
|
310
|
+
|
|
311
|
+
FieldTypeDescription`tool_name`stringName of the MCP tool that was executed`tool_input`stringJSON params string passed to the tool`result_json`stringJSON string of the tool response`duration`numberDuration in milliseconds spent executing the MCP tool (excludes approval wait time)
|
|
312
|
+
#### afterFileEdit
|
|
313
|
+
|
|
314
|
+
Fires after the Agent edits a file; useful for formatters or accounting of agent-written code.
|
|
315
|
+
|
|
316
|
+
```
|
|
317
|
+
// Input
|
|
318
|
+
{
|
|
319
|
+
"file_path": "<absolute path>",
|
|
320
|
+
"edits": [{ "old_string": "<search>", "new_string": "<replace>" }]
|
|
321
|
+
}
|
|
322
|
+
```
|
|
323
|
+
|
|
324
|
+
#### beforeTabFileRead
|
|
325
|
+
|
|
326
|
+
Called before Tab (inline completions) reads a file. Enable redaction or access control before Tab accesses file contents.
|
|
327
|
+
|
|
328
|
+
**Key differences from `beforeReadFile`:**
|
|
329
|
+
|
|
330
|
+
- Only triggered by Tab, not Agent
|
|
331
|
+
- Does not include `attachments` field (Tab doesn't use prompt attachments)
|
|
332
|
+
- Useful for applying different policies to autonomous Tab operations
|
|
333
|
+
|
|
334
|
+
```
|
|
335
|
+
// Input
|
|
336
|
+
{
|
|
337
|
+
"file_path": "<absolute path>",
|
|
338
|
+
"content": "<file contents>"
|
|
339
|
+
}
|
|
340
|
+
|
|
341
|
+
// Output
|
|
342
|
+
{
|
|
343
|
+
"permission": "allow" | "deny"
|
|
344
|
+
}
|
|
345
|
+
```
|
|
346
|
+
|
|
347
|
+
#### afterTabFileEdit
|
|
348
|
+
|
|
349
|
+
Called after Tab (inline completions) edits a file. Useful for formatters or auditing of Tab-written code.
|
|
350
|
+
|
|
351
|
+
**Key differences from `afterFileEdit`:**
|
|
352
|
+
|
|
353
|
+
- Only triggered by Tab, not Agent
|
|
354
|
+
- Includes detailed edit information: `range`, `old_line`, and `new_line` for precise edit tracking
|
|
355
|
+
- Useful for fine-grained formatting or analysis of Tab edits
|
|
356
|
+
|
|
357
|
+
```
|
|
358
|
+
// Input
|
|
359
|
+
{
|
|
360
|
+
"file_path": "<absolute path>",
|
|
361
|
+
"edits": [
|
|
362
|
+
{
|
|
363
|
+
"old_string": "<search>",
|
|
364
|
+
"new_string": "<replace>",
|
|
365
|
+
"range": {
|
|
366
|
+
"start_line_number": 10,
|
|
367
|
+
"start_column": 5,
|
|
368
|
+
"end_line_number": 10,
|
|
369
|
+
"end_column": 20
|
|
370
|
+
},
|
|
371
|
+
"old_line": "<line before edit>",
|
|
372
|
+
"new_line": "<line after edit>"
|
|
373
|
+
}
|
|
374
|
+
]
|
|
375
|
+
}
|
|
376
|
+
|
|
377
|
+
// Output
|
|
378
|
+
{
|
|
379
|
+
// No output fields currently supported
|
|
380
|
+
}
|
|
381
|
+
```
|
|
382
|
+
|
|
383
|
+
#### beforeSubmitPrompt
|
|
384
|
+
|
|
385
|
+
Called right after user hits send but before backend request. Can prevent submission.
|
|
386
|
+
|
|
387
|
+
```
|
|
388
|
+
// Input
|
|
389
|
+
{
|
|
390
|
+
"prompt": "<user prompt text>",
|
|
391
|
+
"attachments": [
|
|
392
|
+
{
|
|
393
|
+
"type": "file" | "rule",
|
|
394
|
+
"filePath": "<absolute path>"
|
|
395
|
+
}
|
|
396
|
+
]
|
|
397
|
+
}
|
|
398
|
+
|
|
399
|
+
// Output
|
|
400
|
+
{
|
|
401
|
+
"continue": true | false,
|
|
402
|
+
"user_message": "<message shown to user when blocked>"
|
|
403
|
+
}
|
|
404
|
+
```
|
|
405
|
+
|
|
406
|
+
Output FieldTypeDescription`continue`booleanWhether to allow the prompt submission to proceed`user_message`string (optional)Message shown to the user when the prompt is blocked
|
|
407
|
+
#### afterAgentResponse
|
|
408
|
+
|
|
409
|
+
Called after the agent has completed an assistant message.
|
|
410
|
+
|
|
411
|
+
```
|
|
412
|
+
// Input
|
|
413
|
+
{
|
|
414
|
+
"text": "<assistant final text>"
|
|
415
|
+
}
|
|
416
|
+
```
|
|
417
|
+
|
|
418
|
+
#### afterAgentThought
|
|
419
|
+
|
|
420
|
+
Called after the agent completes a thinking block. Useful for observing the agent's reasoning process.
|
|
421
|
+
|
|
422
|
+
```
|
|
423
|
+
// Input
|
|
424
|
+
{
|
|
425
|
+
"text": "<fully aggregated thinking text>",
|
|
426
|
+
"duration_ms": 5000
|
|
427
|
+
}
|
|
428
|
+
|
|
429
|
+
// Output
|
|
430
|
+
{
|
|
431
|
+
// No output fields currently supported
|
|
432
|
+
}
|
|
433
|
+
```
|
|
434
|
+
|
|
435
|
+
FieldTypeDescription`text`stringFully aggregated thinking text for the completed block`duration_ms`number (optional)Duration in milliseconds for the thinking block
|
|
436
|
+
#### stop
|
|
437
|
+
|
|
438
|
+
Called when the agent loop ends. Can optionally auto-submit a follow-up user message to keep iterating.
|
|
439
|
+
|
|
440
|
+
```
|
|
441
|
+
// Input
|
|
442
|
+
{
|
|
443
|
+
"status": "completed" | "aborted" | "error",
|
|
444
|
+
"loop_count": 0
|
|
445
|
+
}
|
|
446
|
+
```
|
|
447
|
+
|
|
448
|
+
```
|
|
449
|
+
// Output
|
|
450
|
+
{
|
|
451
|
+
"followup_message": "<message text>"
|
|
452
|
+
}
|
|
453
|
+
```
|
|
454
|
+
|
|
455
|
+
- The optional `followup_message` is a string. When provided and non-empty, Cursor will automatically submit it as the next user message. This enables loop-style flows (e.g., iterate until a goal is met).
|
|
456
|
+
- The `loop_count` field indicates how many times the stop hook has already triggered an automatic follow-up for this conversation (starts at 0). To prevent infinite loops, a maximum of 5 auto follow-ups is enforced.
|
|
457
|
+
|
|
458
|
+
## Troubleshooting
|
|
459
|
+
|
|
460
|
+
**How to confirm hooks are active**
|
|
461
|
+
|
|
462
|
+
There is a Hooks tab in Cursor Settings to debug configured and executed hooks, as well as a Hooks output channel to see errors.
|
|
463
|
+
|
|
464
|
+
**If hooks are not working**
|
|
465
|
+
|
|
466
|
+
- Restart Cursor to ensure the hooks service is running.
|
|
467
|
+
- Ensure hook script paths are relative to `hooks.json` when using relative paths.
|
|
@@ -0,0 +1,105 @@
|
|
|
1
|
+
# Modes
|
|
2
|
+
|
|
3
|
+
Agent offers different modes optimized for specific tasks. Each mode has different capabilities and tools enabled to match your workflow needs.
|
|
4
|
+
|
|
5
|
+
Understanding [how agents work](/learn/agents) and [tool calling fundamentals](/learn/tool-calling) will help you choose the right mode for your task.
|
|
6
|
+
|
|
7
|
+
ModeForCapabilitiesTools**[Agent](#agent)**Complex features, refactoringAutonomous exploration, multi-file editsAll tools enabled**[Ask](#ask)**Learning, planning, questionsRead-only exploration, no automatic changesSearch tools only**[Plan](#plan)**Complex features requiring planningCreates detailed plans before execution, asks clarifying questionsAll tools enabled**[Debug](#debug)**Tricky bugs, regressionsHypothesis generation, log instrumentation, runtime analysisAll tools + debug server
|
|
8
|
+
## Agent
|
|
9
|
+
|
|
10
|
+
The default mode for complex coding tasks. Agent autonomously explores your codebase, edits multiple files, runs commands, and fixes errors to complete your requests.
|
|
11
|
+
|
|
12
|
+
## Ask
|
|
13
|
+
|
|
14
|
+
Read-only mode for learning and exploration. Ask searches your codebase and provides answers without making any changes - perfect for understanding code before modifying it.
|
|
15
|
+
|
|
16
|
+
## Plan
|
|
17
|
+
|
|
18
|
+
Plan Mode creates detailed implementation plans before writing any code. Agent researches your codebase, asks clarifying questions, and generates a reviewable plan you can edit before building.
|
|
19
|
+
|
|
20
|
+
Press Shift+Tab from the chat input to rotate to Plan Mode. Cursor also suggests it automatically when you type keywords that indicate complex tasks.
|
|
21
|
+
|
|
22
|
+
### How it works
|
|
23
|
+
|
|
24
|
+
1. Agent asks clarifying questions to understand your requirements
|
|
25
|
+
2. Researches your codebase to gather relevant context
|
|
26
|
+
3. Creates a comprehensive implementation plan
|
|
27
|
+
4. You review and edit the plan through chat or markdown files
|
|
28
|
+
5. Click to build the plan when ready
|
|
29
|
+
|
|
30
|
+
Plans open as ephemeral virtual files that you can view and edit. To save a plan to your workspace, click "Save to workspace" to store it in `.cursor/plans/` for future reference, team sharing, and documentation.
|
|
31
|
+
|
|
32
|
+
## Debug
|
|
33
|
+
|
|
34
|
+
Debug Mode helps you find root causes and fix tricky bugs that are hard to reproduce or understand. Instead of immediately writing code, the agent generates hypotheses, adds log statements, and uses runtime information to pinpoint the exact issue before making a targeted fix.
|
|
35
|
+
|
|
36
|
+
### When to use Debug Mode
|
|
37
|
+
|
|
38
|
+
Debug Mode works best for:
|
|
39
|
+
|
|
40
|
+
- Challenging bugs or regressions that can be reproduced
|
|
41
|
+
- Performance problems and memory leaks
|
|
42
|
+
|
|
43
|
+
### How it works
|
|
44
|
+
|
|
45
|
+
1. **Explore and hypothesize**: The agent explores relevant files, builds context, and generates hypotheses about potential root causes.
|
|
46
|
+
2. **Add instrumentation**: The agent adds log statements that send data to a local debug server running in a Cursor extension.
|
|
47
|
+
3. **Reproduce the bug**: Debug Mode asks you to reproduce the bug and provides specific steps. This keeps you in the loop and ensures the agent captures real runtime behavior.
|
|
48
|
+
4. **Analyze logs**: After reproduction, the agent reviews the collected logs to identify the actual root cause based on runtime evidence.
|
|
49
|
+
5. **Make targeted fix**: The agent makes a focused fix that directly addresses the root cause—often just a few lines of code.
|
|
50
|
+
6. **Verify and clean up**: You can re-run the reproduction steps to verify the fix. Once confirmed, the agent removes all instrumentation.
|
|
51
|
+
|
|
52
|
+
### Tips for Debug Mode
|
|
53
|
+
|
|
54
|
+
- **Provide detailed context**: The more you describe the bug and how to reproduce it, the more the agent will add relevant instrumentation.
|
|
55
|
+
- **Follow reproduction steps**: Execute the steps the agent provides to ensure logs capture the actual issue.
|
|
56
|
+
- **Reproduce multiple times if needed**: Reproducing the bug multiple times may help the agent identify a particularly tricky problem.
|
|
57
|
+
|
|
58
|
+
## Custom slash commands
|
|
59
|
+
|
|
60
|
+
For specialized workflows, you can create [custom slash commands](/docs/agent/chat/commands) that combine specific instructions with tool limitations.
|
|
61
|
+
|
|
62
|
+
Custom modes are deprecated in Cursor 2.1. Users with custom modes can select the "Export Custom Modes" option to transition their modes to [custom commands](/docs/agent/chat/commands).
|
|
63
|
+
|
|
64
|
+
### Examples
|
|
65
|
+
|
|
66
|
+
### Learn
|
|
67
|
+
|
|
68
|
+
### Refactor
|
|
69
|
+
|
|
70
|
+
### Debug
|
|
71
|
+
|
|
72
|
+
Create a `/debug` command that instructs the agent to investigate issues thoroughly before proposing fixes. Include in the prompt: "Investigate the issue using search tools and terminal commands first. Only propose fixes after thoroughly understanding the root cause."
|
|
73
|
+
|
|
74
|
+
See the [Commands documentation](/docs/agent/chat/commands) for details on creating custom slash commands.
|
|
75
|
+
|
|
76
|
+
## Switching modes
|
|
77
|
+
|
|
78
|
+
- Use the mode picker dropdown in Agent
|
|
79
|
+
- Press Cmd+.Ctrl+. for quick switching
|
|
80
|
+
- Set keyboard shortcuts in [settings](#settings)
|
|
81
|
+
|
|
82
|
+
## Settings
|
|
83
|
+
|
|
84
|
+
All modes share common configuration options:
|
|
85
|
+
|
|
86
|
+
SettingDescriptionModelChoose which AI model to useKeyboard shortcutsSet shortcuts to switch between modes
|
|
87
|
+
Mode-specific settings:
|
|
88
|
+
|
|
89
|
+
ModeSettingsDescription**Agent**Auto-run and Auto-fix ErrorsAutomatically run commands and fix errors**Ask**Search CodebaseAutomatically find relevant files
|
|
90
|
+
## Changelog
|
|
91
|
+
|
|
92
|
+
### Custom modes removed
|
|
93
|
+
|
|
94
|
+
Custom modes have been removed from Cursor. If you previously used custom modes to create specialized workflows with specific tool combinations, you can now achieve the same functionality using [custom slash commands](/docs/agent/chat/commands).
|
|
95
|
+
|
|
96
|
+
Custom slash commands allow you to:
|
|
97
|
+
|
|
98
|
+
- Define reusable workflows triggered with a `/` prefix
|
|
99
|
+
- Include instructions about tool usage directly in the command prompt
|
|
100
|
+
- Share commands across your team via team commands
|
|
101
|
+
- Store commands in your project's `.cursor/commands` directory
|
|
102
|
+
|
|
103
|
+
To limit which tools the agent uses, simply include those instructions as part of the command prompt. For example, a command that should only use search tools might include: "Use only search tools (read file, codebase search, grep) - do not make any edits or run terminal commands."
|
|
104
|
+
|
|
105
|
+
See the [Commands documentation](/docs/agent/chat/commands) for complete details on creating and using custom slash commands.
|