Your First Project in Cursor: Open a Folder and Run Agent

Cursor opens a folder, not a file. That is the habit to break if you are coming from an editor where you open individual files: the folder you choose is what Agent searches.

1. 1Open Cursor.
2. 2Click File > Open Folder.
3. 3Select the folder for your project.

The folder you pick is, I think, a bigger decision than the dialog makes it look. Cursor indexes the whole workspace, which means the folder you opened and everything under it, so pointing it at the directory that holds five checkouts gives the agent five projects to search through. Open the repo root.

Going one level too deep fails more quietly. Open src/ on its own and the agent reads everything under it, so nothing looks broken, while the lockfile and the config one level up sit outside the workspace and never make it into the index it searches.

When a first session goes badly, the folder that is actually open is the thing I check before the prompt or the model.

Agent is Cursor's AI assistant, and Cursor is specific about its reach: it can search your codebase, edit files, and run terminal commands. Three steps to the first run.

1. 1Open the Agent panel: ⌘+I on Mac, Ctrl+I on Windows and Linux.
2. 2Type a request. Cursor's own example: "Add a dark mode toggle to the settings page."
3. 3Hit send. Agent explores your codebase, edits files, and shows its changes.

Cursor's own example, a dark mode toggle on the settings page, is a better first request than it looks. You can confirm it by opening the page and clicking the thing, which means the review step gets practised on a change you can actually see. Pick something checkable that way, even if it is smaller than what you came here to build.

Settle the terminal question before you send anything. Whether a command runs on its own or pauses for your approval is decided by your Run Mode setting rather than by the model, and the terminal tool page covers what each option allows.

You can keep typing while Agent works. Pressing Enter queues the message so it runs after the current task. That is what you want for a clarification, and the opposite of what you want when you have just watched the run head somewhere wrong. ⌘+↵ (Ctrl+↵ on Windows and Linux) skips the queue and sends immediately, joining your text to the most recent user message rather than waiting for a turn that has not started. Cursor's docs point at that shortcut specifically for interrupting or redirecting work in progress.

Yes. The same agents run from the browser at cursor.com/agents as Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition., for work you want to continue without your machine involved. The full behaviour of Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition. is documented in the agent overview.

That equivalence carries a setup cost the local path does not. A cloud agent works against a connected GitHub, GitLab, Azure DevOps or Bitbucket account and the repositories you select, on a machine Cursor provisions, so before it can install dependencies and run your tests somebody has to configure an environment. For a first project, the folder on your disk is less work.

Agent's edits are applied as it works, so you are reviewing a change that already exists rather than approving one before it lands. Review them in the diff view and reject anything you do not want.

The usual advice is to read every line of the diff. Which is realistic on a twelve-line change and quietly optimistic on a two-hundred-line one, so I would start somewhere else: check the file list against the task you described, then read. A change to a config file you never mentioned deserves more of your attention than three obviously-correct lines in the component you asked about.

On a first project the diff view is the whole review system, since there is no pull request and nobody else looking at it. Two or three people can work that way for a surprisingly long time. Past that the diff in your editor is invisible to everyone but you, and the gate has to move somewhere shared. Agent Review runs on a commit or on your full local diff against main and loads team standards from .cursor/BUGBOT.md, while BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. reviews the pull request itself.

Restore a checkpoint. Agent snapshots your files during a session, automatically, before it makes significant changes, and each prompt in the chat timeline carries its own restore control. Click one to preview your files at that point, then restore to put every modified file back to that state.

The checkpoint you pick decides how much survives. Restore from the prompt that went wrong and the earlier edits stay where they are. Go back to the first prompt instead and you lose the good work along with the bad one, then get to run the whole session again.

Checkpoints are stored locally and sit outside Git, and Cursor is blunt about the boundary, telling you to use them for undoing agent changes and Git for version control. They cover the wrong turn inside a session and nothing wider than that. A commit before the first agent run is worth the ten seconds it costs. The failure I have watched is not one bad edit but an afternoon of them, and by that point there is no clean checkpoint left to go back to.

You can also reject the change outright and send the request again with the constraint you left out. On a small first change that is usually quicker than picking through the diff deciding what to keep.

By default Agent searches your codebase itself, so on a first project you often do not need to do anything. When you do want to point it somewhere specific, type @ in the chat input and name the file or folder, for example @auth.ts or @src/components/.

The context that changes a first run most is probably not a file at all. It is the sentence where you say how the agent should know it worked, naming the command that should pass or the page that should look different afterwards. Agent can run that command and read the output, which turns a success criterion into something it acts on.

Rules get one line in that table and deserve a caveat. A rule is a standing instruction that applies to every request it matches, whether or not you remember writing it, so a day-one rules file tends to age badly. Watch what the agent gets wrong on your codebase, then write the rule about that.