The Cursor editor for people coming from VS Code, and what changes day to day

Searches for the Cursor editor return two unrelated things: tools for drawing mouse pointers, and the code editor built around an AI agent. This page is about the second one. For anyone already using VS Code, the useful question is not what the marketing page claims, but what actually changes between opening the editor in the morning and closing it at night. Most of the interface is the same. A handful of specific things are not, and two or three of them change the shape of the work.

The first hour: importing a setup that already exists

Cursor is built on the VS Code codebase, which is why moving in takes minutes rather than an afternoon. The settings panel has a one-click import under General and Account: clicking it transfers extensions, themes, settings, and keybindings from the local VS Code installation.

For a move between machines, or for more control, profiles can be exported and imported manually through the Command Palette with Preferences: Open Profiles (UI), exporting to a file or a GitHub Gist and importing on the other side. That path also covers the case where only one of several profiles should come across.

One consequence of the shared codebase is worth knowing before a bug report gets written.

We regularly rebase Cursor onto the latest VS Code version to stay current with features and fixes. To ensure stability, Cursor often uses slightly older VS Code versions. Source: cursor.com

A feature that shipped in VS Code last week may not be present yet. That is a deliberate lag, not a defect, and it matters mainly for anyone depending on very new editor APIs.

Two settings panels, and which one to open

The first genuine friction is that there are now two settings surfaces. Cursor Settings, opened from the Command Palette by typing Cursor Settings, holds the AI configuration: models, Tab behavior, agent approvals, rules. The familiar VS Code settings live where they always did, under Preferences: Open Settings (UI).

Searching for a font size setting in the wrong panel is the most common first-day confusion. The rule of thumb is simple: anything involving a model, an agent, or a suggestion is in Cursor Settings, and everything else is in the VS Code settings.

The other visible change is the activity bar. Cursor makes it horizontal to leave more room for the chat interface. For anyone whose muscle memory depends on the vertical strip of icons, the documentation gives the exact setting: search for workbench.activityBar.orientation in the VS Code settings, set it to vertical, and restart.

Tab completion is the feature that changes typing

Inline completion exists in other editors, so it is easy to assume Tab is the same feature with a different badge. Its behavior differs in ways that show up within an hour.

Suggestions appear as grayed-out text ahead of the cursor, based on recent edits, surrounding code, and linter errors. Tab accepts the whole suggestion, Escape rejects it, and Cmd and Right Arrow accepts one word at a time on a Mac. Suggestions are not limited to the line being typed: Tab can modify multiple lines, add missing import statements, and suggest coordinated edits across related code.

Two behaviors go further than autocomplete. After accepting a suggestion, pressing Tab again jumps to the next likely editing location, which removes a scroll or a search. And when a change in one file requires an update in another, a portal window appears at the bottom of the editor offering the jump across files.

That last one is where opinions split. Cross-file edits are genuinely useful during a rename and genuinely distracting while thinking. The controls are in the bottom-right corner of the window: clicking the Tab status indicator allows snoozing for a chosen duration, disabling globally, or disabling for specific file types such as markdown or JSON. Turning Tab off for prose files is the single change that makes the editor calmer for anyone who writes documentation in the same window as code. The keyboard shortcut itself can be remapped by searching for Accept Cursor Tab Suggestions in Keyboard Shortcuts.

The chat panel and its three modes

Cmd+I opens the agent panel, and Shift+Tab cycles between modes. The three are worth separating, because using the wrong one is the most common source of unwanted edits.

Agent mode has full tool access: it searches the codebase, reads and edits files, runs terminal commands, and can control a browser to verify visual changes. Ask mode is read-only and answers questions without making any edits, which suits questions like how an authentication flow works or where a database connection is configured. Plan Mode researches the codebase, asks clarifying questions, and produces a reviewable plan that can be edited before any code is written, with plans saved to the home directory by default and a Save to workspace option for sharing one through the repository.

Mode	What it does	When it fits
Ask	Answers questions, makes no edits	Reading unfamiliar code
Plan	Produces an editable plan first	Features touching many files
Agent	Edits files and runs commands	Work whose shape is already clear

A useful default is to start in Ask or Plan on anything unfamiliar, and reserve Agent mode for work whose shape is already decided.

The terminal inside the editor behaves differently now

The integrated terminal stops being only a place to type. The agent runs shell commands in it, by default using the first terminal profile available, which can be changed through Terminal: Select Default Profile in the Command Palette.

That sharing causes one problem worth knowing in advance, because it looks like a bug. Heavy shell themes, Powerlevel9k and Powerlevel10k among them, can interfere with inline terminal output, making a command's result look truncated or misformatted. The documented workaround is to detect the agent through the CURSOR_AGENT environment variable in the shell configuration and skip the theme when it is set, leaving the prompt intact for normal interactive sessions.

Reviewing what the agent ran is a related habit. Agent Review runs a dedicated review of local changes from inside the editor, configured under Agents in Cursor Settings, and can be set to run automatically after every commit or triggered on demand with /agent-review. Run from the Source Control tab, it compares all local changes against the main branch rather than only the most recent edit, which catches the edit that arrived three tasks ago and was never read.

What changes in the rhythm of a day

The interface changes are small. The change in how time is spent is not.

Reading replaces typing. With an agent producing edits, the bottleneck moves from writing code to reviewing it, and the diff view becomes the most-used part of the editor rather than an occasional stop before a commit. Anyone who skims diffs will feel that habit become expensive quickly.

Undo gets a second mechanism. Checkpoints snapshot modified files before significant agent changes and can be restored from the chat timeline, reverting files without deleting the conversation. The documentation is explicit that they are stored locally, are separate from Git, and should be used only for undoing agent changes rather than as version control. In practice this means commits get more valuable, not less: a checkpoint covers the last few minutes, and a commit covers everything else.

Instructions move into the repository. Rules in .cursor/rules are version-controlled and can apply always, apply when the agent judges them relevant, apply to files matching a pattern, or apply only when called by name. A plain AGENTS.md at the root is the simpler alternative. Writing down the conventions that were previously carried in someone's head becomes part of the work.

Context needs boundaries. A .cursorignore file excludes paths from AI context, .gitignore is respected automatically, and environment files and lock files are already excluded by default. The documentation notes that terminal commands and MCP tools run outside those file access controls and may still read ignored files, so the ignore file is a context filter rather than a wall.

Approvals become a setting rather than an afterthought. Run Modes decide whether shell commands run immediately, run in a sandbox, or wait for review, and the choice lives in Settings under Agents.

Cost becomes part of the editor

One more thing changes for anyone arriving from VS Code, and it has nothing to do with the interface. VS Code itself is free, and its cost model is whatever the AI extension in use charges. In Cursor, the editor and the usage are the same subscription, which puts a meter next to the editing window.

The published plans are Hobby at no cost, Pro at $20 a month, Pro+ at $60, Ultra at $200, and Teams from $40 per user per month. Most plans carry two monthly usage pools, one for Cursor's own models and one for third-party models charged at provider prices, and the model selected changes how fast the included amount is consumed. Usage resets with the billing cycle and does not roll over. When it runs out, the choices are on-demand billing or a higher plan. On individual plans, requests made with a personal API key do not draw from either pool, since the provider bills for them directly.

The effect on daily work is subtle but real: a long agent run on a frontier model is no longer a free action. The Spending tab in the dashboard shows both pools in real time, and checking it after the first week is more informative than any estimate made in advance.

The part the editor does not solve

After a few weeks, a familiar pattern appears. The editor holds the project. A terminal window holds the commands that are not run by the agent. A file manager holds everything that is not in the repository: reference material, assets, downloads, screenshots waiting to be renamed. A fourth window may hold notes.

The editor is excellent at the first of those and indifferent to the rest, because it is organized around a single opened project. Work that spans an external drive, a notes vault, and a repository does not have a home in it. That is not a flaw in Cursor. It is the boundary of what a code editor is for.

The usual response is to keep more windows open and switch between them. The alternative is to collapse the windows that exist only to bridge the others: a file manager with a built-in terminal puts the folder and the shell acting on it in one place, which is what Features sets out, and how that differs from Finder and from other file managers is on Compared with other file managers.

What to change first

Import the VS Code profile, then spend five minutes in Cursor Settings on two things: the Run Mode that decides when the agent may run commands, and Tab behavior for file types where suggestions get in the way. After a week, count the window switches; if most of them leave the editor for a folder or a terminal, the fix is the workspace around the editor, which is what Atriens is built for.