Cursor

The Codex lesson covered a tool you run in a terminal, and Claude Code is the same shape. Cursor flips the order. It is a full code editor, the kind with a file tree on the left, your code in the middle, and a terminal at the bottom, and the coding agent lives in a pane on the right. You never leave the window. The agent edits the file you are looking at, the change appears highlighted in place, and you decide whether to keep it. As of September 2026 that is still the clearest difference between Cursor and everything else in this module.

Every product claim here was checked against cursor.com/docs on 2026-09-17. Cursor ships often, so treat specifics as a snapshot.

The editor first

If you have used VS Code, Cursor will feel familiar on purpose. The docs say it shares the same default keyboard shortcuts as VS Code, and Settings has a one-click import that brings over your extensions, themes, settings, and keybindings. One difference to know: Cursor installs extensions from the Open VSX registry rather than the VS Code Marketplace, so a few extensions are missing or behave slightly differently. You can run both editors on the same project. They are separate applications.

Why does it matter that the AI lives in an editor? Because the editor already knows things a terminal has to be told: which file is open, which lines you selected, what the linter is complaining about, what you edited thirty seconds ago. Tap through the four regions below to see where each piece of the work happens.

desert-shade-tint/
  AGENTS.md
  index.html  M
  styles.css  M
  images/

  </section>
+ <form id="contact" class="card">
+   <label for="name">Name</label>
+   <input id="name" name="name">
+   <button>Send</button>
+ </form>

Agent  |  Plan  |  Ask

You: Add a contact form...
Agent: Read AGENTS.md
Agent: Edited 2 files
Review changes in the diff view

$ python3 -m http.server 8080
Serving HTTP on :: port 8080

[Auto-review: npm test]
Run  |  Skip

Three ways the AI shows up

Cursor is not one AI feature. It is three, and they sit at different distances from your cursor. A cursor here means the blinking insertion point in the editor, the thing the product is named after.

• Tab. Autocomplete that suggests code as you type, based on your recent edits, the surrounding code, and linter errors. It can change several lines at once, add a missing import, and after you accept one edit it predicts where you will edit next and jumps there when you press Tab again, even in another file. Tab accepts the whole suggestion, Cmd+Right accepts it a word at a time, and Escape rejects it. Pro and above include unlimited Tab completions.
• Inline Edit. Select some code, press Cmd+K (Ctrl+K on Windows), type what you want changed, press Return. The edit lands in place without opening the chat pane. Opt+Return switches the same box into question mode, where you ask about the selected code instead of changing it. Cmd+L hands the selection to the Agent when the job turns out to be bigger than one spot.
• Agent. The full coding agent, opened with Cmd+I in the side pane. It reads files, searches the codebase, edits multiple files, runs terminal commands, and can drive a browser for screenshots. This is the part that matches Claude Code and Codex.

The habit that makes Cursor productive is picking the right one. A rename inside one function is Tab or Inline Edit. A feature that touches four files is the Agent.

The agent, and the diff review that makes it different

The Agent pane has a mode picker at the top. Agent mode edits files. Plan mode researches the codebase, asks clarifying questions, writes an implementation plan you can edit, and waits for your approval before building. Ask mode is read-only: it answers questions and explores code without making any edits. The docs also name Debug and Manual modes. Shift+Tab flips between modes from the keyboard. If you did the Claude Code module, Plan and Ask map closely to plan mode there.

Two safety pieces matter before you let it loose. The agent creates a checkpoint before significant changes, a saved copy of every file it is about to touch, and you can restore one to roll back everything after that point. Terminal commands go through a run mode. The default, Auto-review, runs commands in a sandbox when it can and sends the rest through a safety review that stops and asks you before higher-risk calls. The other two modes are Allowlist and Run Everything. The edits themselves appear in the editor as the agent works, in what the docs call the diff view, and you reject anything you do not want.

Step through the session below: rules read first, a search, edits that land in the editor, a review step where a human catches a skipped rule, and a terminal command at the end.

Rules: AGENTS.md and .cursor/rules

A rules file is a plain text file of standing instructions the agent reads before every conversation. Cursor gives you two kinds, and you can use both.

The simple one is AGENTS.md in the project root. The docs describe it as a plain markdown file for defining agent instructions, offered as an alternative to the rules folder for straightforward cases. Nested AGENTS.md files in subdirectories are supported too: their instructions combine with the parent directories, and the more specific file wins where they conflict. This is the same file Codex reads, which is why the Claude Code module spends a lesson on keeping one AGENTS.md for every tool. Here is the one from the session:

# Desert Shade Tint
- Plain HTML and CSS only, no build step.
- Phone number is (435) 555-0142, never invent another.
- Keep every form accessible: labels, not placeholders.

The richer one is project rules: files in .cursor/rules/, checked into version control, scoped to the codebase. Each rule must use the .mdc extension. A plain .md file dropped in that folder is ignored, because the rules system needs the frontmatter, the small block of metadata between two lines of three dashes at the top. That metadata is what makes project rules different from AGENTS.md. Three keys matter:

• alwaysApply: true means the rule loads in every chat.
• description lets the agent decide on its own when the rule is relevant and pull it in.
• globs attaches the rule only when a matching file is in play, for example every page under a services folder.

A rule with none of those set is manual: it loads only when you @-mention it in chat. Here is a scoped rule for the tint shop site:

---
description: "Standards for pages under /services"
globs: services/**/*.html
alwaysApply: false
---
Every services page ends with a call-to-action block that
links to /contact. Use the .card class, never inline styles.

Two more layers exist. User rules live in your Cursor settings and apply to every project you open, though the docs note they are not applied to Inline Edit. Team rules are set by a Teams admin and take precedence. The order is Team, then Project, then User. If a rule seems to be ignored, check whether a higher layer contradicts it before you rewrite it.

MCP servers, the CLI, and cloud agents

MCP (Model Context Protocol) is the open standard for handing an agent a tool it did not ship with: a database, a ticket tracker, a browser. Cursor reads MCP servers from two files. A project-specific .cursor/mcp.json makes a server available in that folder only, and ~/.cursor/mcp.json in your home directory makes it available everywhere. Three transports are supported: stdio for a local process Cursor starts itself, and SSE or Streamable HTTP for a server that already runs somewhere. The agent picks relevant tools on its own from the available list, and by default asks your approval before running one. A minimal project file looks like this:

{
  "mcpServers": {
    "server-name": {
      "command": "node",
      "args": ["server.js"]
    }
  }
}

Cursor also has a terminal agent of its own. The command is agent, installed with a one-line script from cursor.com/install, and it supports the same three modes as the editor. agent -p "find and fix the broken link" runs it non-interactively for scripts and CI. So the editor-versus-CLI line is about which surface you reach for first, not a wall.

Cloud Agents run the same agent on a remote virtual machine, so your laptop does not need to stay on. You start one from a Cloud option in the editor, from Cursor on the web or iOS, from Slack with an @cursor mention, or from a comment on a GitHub or Bitbucket pull request, and it can open a pull request when done. Requirements: an admin connects source control first, you must be on a paid plan, and cloud usage is billed at API pricing for the model you pick, with a spend limit you set the first time.

Plans, as of September 2026: the docs list Pro, Pro Plus, and Ultra for individuals, Teams with Standard and Premium seats, and Enterprise with custom pricing. Pro and up include unlimited Tab completions, Cloud Agents, and Bugbot, Cursor's code review add-on. Prices move, so read the current numbers at cursor.com/docs/models-and-pricing rather than trusting a screenshot. That page also gives typical monthly usage bands for daily and power users, a more useful number than the sticker price.

When an editor beats a CLI, and when it does not

Honest version, from using both. An editor wins when:

• You need to see the diff in context. Reviewing a change against the lines around it is faster in place than in a scrolling terminal, and you catch more.
• The codebase is unfamiliar. Ask mode plus a file tree plus jump-to-definition beats asking an agent to describe a project to you.
• The work is front-end. CSS and layout tweaks are visual. Tab and Inline Edit on a file you can see beat describing a margin change in words.
• The person never wants a terminal. Plenty of capable people do not. Cursor gives them the full agent with a button for every command.

A CLI wins when:

• The job runs unattended. A headless agent -p in a script, a scheduled task, or a CI pipeline has no window to look at.
• You are on a remote machine. Over SSH there is no editor. The terminal agent is the whole interface.
• The task is long and multi-file. Forty edits streaming into an editor is noise. A summary and a git diff at the end is signal.
• You already live in the terminal. An editor pane is a detour.

Most people who write code every day end up with both open. The editor is where they read and the terminal is where they delegate. And you do not have to pick one editor to get one agent.

Both Anthropic and OpenAI ship editor extensions, and both document Cursor as a supported editor. As of September 2026 the Claude Code docs have a direct Install for Cursor link, note that the extension also installs in other VS Code forks from the Open VSX registry, and say that if an editor cannot install the extension you can run claude in its integrated terminal instead, since the CLI works in any terminal. The extension gives you a chat panel, inline diffs, and plan review. The CLI in the bottom terminal panel gives you every feature, including the ones the extension leaves out.

The Codex IDE extension lists VS Code, Cursor, Windsurf, and VS Code Insiders as compatible editors. It adds a composer that can reference open files and selected code, an in-place diff review, and a handoff to Codex cloud for tasks that need more time. A common setup: Cursor for Tab and visual diffs, plus one CLI agent in the terminal for long multi-file jobs. The picking one lesson covers running two at once.

Try this yourself

Twenty minutes, any folder. Open it in Cursor, create a file named AGENTS.md at the root, and paste three rules that are easy to check. Then ask the Agent for one small change and watch which rules it followed.

# Rules for this folder
- Every new file starts with a one-line comment saying what it is for.
- Use the word "customer", never "user", in any text a person will read.
- Never add a dependency without asking first.

Then in the Agent pane (Cmd+I), Agent mode:
Add a short README to this folder that explains what it contains.

Read the diff before you keep it. Did the README start with a comment? Did it say customer? Did it stay dependency-free? If it missed one, tell it which rule it skipped and watch the follow-up edit. Then move one rule into .cursor/rules/style.mdc with alwaysApply: true and run the same request again. Now you know from your own screen which file Cursor listens to.