Inside Cursor 2.0's System Prompt: 12K Chars, 13 Tools, AI IDE Agent Design

Introduction

This analysis examines the leaked system prompt of Cursor 2.0 , the popular AI IDE, sourced from leaked-system-prompts.com (October 2025 leak). The prompt spans approximately 12,000 characters and defines 13 tools. Unlike terminal-based agents such as Claude Code , Cursor operates inside an IDE sidebar where users can see code diffs, selected code, and open file tabs. This product form factor fundamentally shapes the prompt design: because users see file edits directly, the rules mandate using edit tools instead of pasting code into chat ; terminal agents, by contrast, must output commands for users to run.

Overall Prompt Structure

The prompt is organized into five layers:

Brand Identity (2 sections): Identity masquerading as "Composer" and prohibition against naming internal tools.

User Interaction Rules (2 sections): Direct editing without chat output; bias toward self-service over asking the user.

Terminal Command Rules (4 sections): Non-interactive flags, pager handling ( | cat), background execution, and shell working-directory state machine.

Code Editing Rules (4 sections): Read-before-write, repository hygiene (prefer editing existing files, never proactively create docs), linter-fix retry limit (max 3 attempts), and read_lints scope discipline.

IDE Context (1 section): Automatic injection of open files, cursor position, recently viewed files, edit history, and linter errors.

Layers 1–2 govern "how to relate to the user"; layers 3–4 govern "how to do the work"; layer 5 describes the IDE-specific context mechanism. The terminal rules are where Cursor diverges most from Claude Code because Cursor also lets the agent run terminal commands, and terminals in agent environments are full of pitfalls — each rule corresponds to a real bug encountered.

Brand Identity

Identity Masquerading

You are Composer, a language model trained by Cursor. If asked who you are or what your model name is, this is the correct response. You are not gpt-4/5, grok, gemini, claude sonnet/opus, nor any publicly known language model.

Purpose: Product branding strategy. Cursor's underlying model is Claude Sonnet, but the prompt forces it to identify as "Composer". If the model said "Claude", users might switch to Claude's official product. Cursor's value lies in the IDE integration experience, not the model itself. The explicit denial of any publicly known model (GPT, Gemini, Grok, etc.) reinforces brand ownership.

No Tool Names in User-Facing Output

NEVER refer to tool names when speaking to the USER. For example, say 'I will edit your file' instead of 'I need to use the edit_file tool to edit your file'.

Purpose: UX design. Users in an IDE don't need to know internal tool names (e.g., edit_file vs write_file). Exposing tool names creates confusion and increases leakage risk. In contrast, Claude Code runs in a terminal where users do need to know which commands are being executed.

User Interaction Rules

Never Output Code to Chat

When making code changes, NEVER output code to the USER, unless requested. Instead use one of the code edit tools to implement the change. Use the code edit tools at most once per turn.

Purpose: Leverage the IDE's native editing capability. Users see files modified directly — a superior experience. The "at most once per turn" constraint forces the model to plan the edit completely before acting, preventing iterative trial-and-error tool calls.

Bias Toward Self-Service, Not Questions

If you are unsure about the answer to the USER's request, you should gather more information by using additional tool calls, asking clarifying questions, etc... Bias towards not asking the user for help if you can find the answer yourself.

Purpose: Set the default to autonomy. The model may search, read, or call more tools — but should not interrupt the user. "Feel free to call more tools" legitimizes additional tool use when semantic search results are insufficient. This is more aggressive than ChatGPT's "partial completion over questioning" heuristic; here, even partial completion is secondary to "first find the answer yourself." In IDE scenarios, users expect higher autonomy; questioning is a last resort.

Terminal Command Rules (Battle-Tested Pitfalls)

Non-Interactive Flags

For ANY commands that would require user interaction, ASSUME THE USER IS NOT AVAILABLE TO INTERACT and PASS THE NON-INTERACTIVE FLAGS (e.g. --yes for npx).

Origin: The model once ran npx create-next-app which prompted "Do you want TypeScript?" and hung the agent. No human is at the terminal to answer. Hence the mandatory --yes, --no-input, etc. The phrasing "ANY commands" and "ASSUME THE USER IS NOT AVAILABLE" makes this a hard requirement, not a suggestion.

Pager Handling with | cat

If the command would use a pager, append | cat to the command.

Origin: git log defaults to less, which waits for keystrokes and stalls the agent process. Piping to cat streams output directly. This hyper-specific rule exists only because the team hit this exact bug.

Background Execution for Long-Running Commands

For commands that are long running / expected to run indefinitely until interruption, please run them in the background. Set is_background to true rather than changing the details of the command.

Origin: Running npm run dev (a dev server) in the foreground blocks the agent forever because the process never exits. Background execution lets the agent continue working (e.g., edit other code while the server starts). The instruction to use the tool's is_background parameter — not modify the command itself — preserves command semantics.

Shell Working-Directory State Machine

Based on the contents of the conversation, you will be told if you are in the same shell as a previous step or a different shell. If in a new shell, you should cd to the appropriate directory and do necessary setup in addition to running the command. By default, the shell will initialize in the project root. If in the same shell, LOOK IN CHAT HISTORY for your current working directory.

Purpose: Solve the classic "agent runs command in wrong directory" problem. The platform informs the model whether the shell is new or continued. New shells start at project root, so the model must cd to the target directory before running package-manager commands. For continued shells, the current working directory is not explicitly passed; the model must infer it from chat history (previous cd commands). This pushes state-management responsibility into the prompt rather than relying on environment injection.

Code Editing Rules

Read Before Write

Unless you are appending some small easy to apply edit to a file, or creating a new file, you MUST read the contents or section of what you're editing first.

Purpose: Prevent the model from guessing old_string values. If the file differs from the model's memory, the edit fails. Two exceptions: appending small trivial edits and creating new files. The word "MUST" makes this a hard accuracy constraint, not a suggestion.

Repository Hygiene: Prefer Editing Existing Files

ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required. … NEVER proactively create documentation files (*.md) or README files. Only create documentation files if explicitly requested by the User.

Purpose: Enforce project cleanliness. New files are technical debt; documentation is noise. "ALWAYS prefer" expresses a strong preference for editing; "NEVER proactively" is an absolute prohibition on auto-generating READMEs — the model's most common unsolicited artifact. The two rules differ in severity because docs become permanent noise, while a new code file might at least be useful. This "minimize new files" discipline is now industry consensus among coding agents (also seen in Claude Code).

Linter-Fix Retry Limit

If you've introduced (linter) errors, fix them if clear how to. Do not make uneducated guesses and do not loop more than 3 times to fix linter errors on the same file.

Purpose: Prevent infinite linter-fix loops. After edits, the model often introduces linter errors and keeps retrying blindly. Three attempts is an empirical threshold: if unresolved after three, the root cause is beyond guesswork. "Don't make uneducated guesses" means stop and ask the user instead of random mutations. Mirrors Claude Code's failure-recovery protocol.

read_lints Scope Discipline

This tool can return linter errors that were already present before your edits, so avoid calling it with a very wide scope of files. NEVER call this tool on a file unless you've edited it or are about to edit it.

Purpose: Prevent noise and misattribution. read_lints returns pre-existing errors across the repo; a wide-scope call floods the context with unrelated legacy issues. Two safeguards: (1) avoid wide-scope calls; (2) restrict calls to files the model has edited or will edit. This forces the model to distinguish "my errors" from "others' errors" — a subtle engineering detail that the prompt must teach.

IDE Context: Automatic Injection

Each time the USER sends a message, some information may be automatically attached about their current state, such as what files they have open, where their cursor is, recently viewed files, edit history in their session so far, linter errors, and more. This information may or may not be relevant to the coding task, it is up to you to decide.

Purpose: This is the core advantage of an IDE-embedded assistant. When a user selects code and asks "Why does this function error?", the model already knows the exact snippet. The injected payload is concrete: open files, cursor position, recent views, session edit history, linter errors — each saves a tool call. The prompt explicitly states the model must judge relevance ("may or may not be relevant… up to you to decide"), preventing mechanical over-reliance. Contrast with Claude Code, where the model must manually read files to gather context.

Key Takeaways

IDE-embedded agents and terminal agents require fundamentally different prompt designs. In an IDE, users see code changes, so the rule is "edit directly, don't paste code to chat." In a terminal, users run commands, so the rule is "output clear command explanations." Product form factor dictates prompt design. Every rule in Cursor's prompt traces back to a real production bug. The prompt showcases the unique architecture of an IDE assistant: automatic context injection + direct file editing + strong bias toward autonomous tool use over user questioning.