# Staying current with Cursor

URL: https://developertoolkit.ai/en/cursor-ide/reference/
Description: Know which Cursor build and SDK each machine runs, read releases against your committed config, and roll updates out behind canary tests.

Staying current with Cursor means knowing which Cursor desktop build and which Cursor SDK version each machine and pipeline runs, reading each release against the configuration your team commits, and moving everyone to a new build only after canary tasks pass.

This hub is for the developer who uses Cursor every day and the tech lead who owns the team's rules, skills, hooks, MCP servers, and any script that drives Cursor's agent. An update lands on Monday. By Wednesday one teammate's agent ignores a rule, another's MCP server is dark, and a third still calls Cloud Agents "Background Agents" in the onboarding doc. Each traces back to nobody knowing what changed or who runs what.

**Documentation freshness**

Covers Cursor 3.24 (released 2026-10-09, according to Cursor's release notes), the Cursor CLI v2026.10.08, and `@cursor/sdk` and `cursor-sdk` 1.0.37 (published 2026-10-07), all checked on 12 October 2026. Feature names, Run modes, and the CLI command were verified against Cursor's documentation and release notes that day. On 26 September 2026 cursor.com was unreachable, so the previous edition of this section pinned no desktop build.

## What you get from the Cursor reference section

- A table that routes your question to the right page.
- The commands that show which Cursor build and SDK a machine and project run.
- A five-step team update routine with an owner and a test-based pass signal.
- Two copy-paste prompts: a Cursor dependency inventory and a stale-name finder.

## Which Cursor reference page do you need?

| Your question | Open | You leave with |
| --- | --- | --- |
| What changed in Cursor, and what is it called now? | [Cursor version history](/en/cursor-ide/reference/changelog/) | The current version and its numbering, changelog entries and weekly builds since August 2026, renamed features, and a release-to-rollout routine |
| How do I update, or roll back a bad update? | [Cursor upgrade guides](/en/cursor-ide/reference/upgrade-guides/) | Update channels, pre-flight and post-update checks, and rollback |
| Should my team adopt a new feature, and how? | [Adopting new Cursor features](/en/cursor-ide/reference/feature-adoption/) | Blast-radius tiers, a worktree trial on merged tickets, and CI gates |
| Which keys save the most time? | [Cursor keyboard shortcuts](/en/cursor-ide/reference/keyboard-shortcuts/) | The shortcuts that matter, grouped by workflow |

## How do you check which Cursor build and SDK a machine and project run?

Record the three lines `cursor --version` prints, with the date; the commit hash is what rollback needs (see [upgrade guides](/en/cursor-ide/reference/upgrade-guides/)). Without `cursor` on your PATH, read the build from the app's About dialog.

Scripts and CI jobs run the Cursor SDK, which has a public version history you can pin, and sometimes the Cursor CLI, which Cursor versions by date (v2026.10.08 on 2026-10-12). Run these at the repository root:

```bash
cursor --version               # desktop build: version, commit hash, architecture
npm view @cursor/sdk version   # latest TypeScript SDK on npm
npm ls @cursor/sdk             # the version this project resolves
pip show cursor-sdk            # the Python SDK installed (needs Python 3.10 or later)
node --version                 # @cursor/sdk declares Node.js 22.13 or later
agent --version                # Cursor CLI version (Cursor versions the CLI by date)
```

A caret or tilde range in `package.json` with no committed lockfile is not a pin; install with `--save-exact` and commit the lockfile. The [Cursor SDK guide](/en/cursor-ide/automate/cursor-sdk/) covers pinning and headless runs.

## How should a team keep Cursor current?

1. Name one owner, usually the tech lead, who reads [Cursor's changelog](https://cursor.com/changelog) and [release notes](https://cursor.com/docs/release-notes) weekly and signs off each rollout.

2. Keep the team's Cursor configuration in the repository: rules, skills, hooks, MCP server configs, and plugins.

3. Pin the SDK exactly in every CI job and container, and move the pin only in a pull request that runs your headless job on a fixture.

4. Keep three to five canary tasks from your backlog, each with acceptance tests written before the agent starts. Run them from the same commit on the current build before you update, record the results, then run them again on the new build, each run in its own worktree.

5. Roll out in two stages: one volunteer for a few working days, then everyone. The owner approves stage two when the canary tests pass and retries and changed-file counts are no higher than on the old build.

The full routine, with a triage prompt and a loaded-config check, is in [the Cursor version history](/en/cursor-ide/reference/changelog/).

## How do you prove a Cursor update is safe without reading every diff?

The pass signal is mechanical: the canary tests, the type check, and the linter exit with status 0 on the new build, with no more agent retries (reruns of the task after a failing test) and no more changed files than on the old build. The owner compares those numbers, not the agent's diffs. If the numbers diverge, move the team back to the previous build using the [rollback steps](/en/cursor-ide/reference/upgrade-guides/) and investigate on one machine. See [reading evidence instead of code](/en/ladder/evidence-not-diffs/).

**Copy-paste prompt: inventory what depends on Cursor in this repository**

```text
Find everything in this repository that depends on Cursor. Search .cursor/,
rule files, skill directories, hook scripts, MCP server configs, plugin
manifests, .github/workflows, Dockerfiles, .devcontainer, package.json,
requirements files, pyproject.toml, and shell scripts for: @cursor/sdk,
cursor-sdk, Cursor CLI calls in print mode (-p or --print), and Cursor
config files.
Output a table: file:line, what it is (rule, skill, hook, MCP server,
plugin, SDK dependency, CLI call), and for SDK dependencies either PINNED
(exact version or lockfile) or UNPINNED (range, "latest", or no version).
Do not edit any files.
```

**Copy-paste prompt: find stale Cursor feature names in our docs**

```text
Search every Markdown and MDX file, prompt file, and review checklist in this
repository for these outdated Cursor terms: "Background Agent", "BugBot",
"BUGBOT", "YOLO mode", "Auto-Run", "Ask Every Time", "Run in Sandbox",
".cursorrules", "Max Mode", and the link path
"cursor.com/docs/api/sdk/typescript".
Only flag "Background Agent" when the sentence is about Cursor; ignore
Claude Code or Codex background agents. Only flag "Max Mode" when the sentence
presents it as a feature of current Cursor plans.
For each hit, output file:line, the sentence, and the current term:
Background Agent -> Cloud Agents; BugBot -> Bugbot; YOLO mode or Auto-Run ->
Run modes (Auto-review, Allowlist, Run Everything); Ask Every Time or Run in
Sandbox -> Allowlist; .cursorrules -> project rules in .cursor/rules/*.mdc or
AGENTS.md; Max Mode -> available only on legacy request-based plans;
cursor.com/docs/api/sdk/typescript -> cursor.com/docs/sdk/typescript.
Do not edit files. End with the total number of hits per term.
```

Check each inventory row against the file it names. For the second prompt, zero hits after your fix pull request is the pass signal.

## What goes wrong when Cursor versions drift?

- **The agent ignores a rule after an update.** Run the loaded-config prompt in [the version history](/en/cursor-ide/reference/changelog/). If the rule is missing, move back to the previous build while you fix the rule file.
- **A CI job fails after an unpinned SDK install.** Pin the version from your last green run: `npm install --save-exact @cursor/sdk@LAST_GOOD_VERSION`. Then read the SDK release before you move the pin.
- **Canary tests pass, but with more retries or larger diffs.** Hold the team rollout, reproduce on the previous build from the same commit, and report both builds' `cursor --version` output to Cursor.
- **A model disappears from the picker.** Pick a candidate from [the models hub](/en/ecosystem/models/) and run the canary set on it before anyone switches.

## Where to go next with Cursor updates

- [Cursor version history](/en/cursor-ide/reference/changelog/) — Verified milestones, renamed features, and the release-to-rollout routine
- [Cursor upgrade guides](/en/cursor-ide/reference/upgrade-guides/) — Update channels, pre-flight checks, and rollback
- [Adopting new Cursor features](/en/cursor-ide/reference/feature-adoption/) — Trial a feature by blast radius and prove it in CI
- [Cursor team and enterprise](/en/cursor-ide/team/) — Shared configuration and administration for teams

The other tools have the same section: [staying current with Claude Code](/en/claude-code/reference/) and [staying current with Codex](/en/codex/reference/).