The first session with a new tool sets the habits, so it should start with the environment rather than with a task. After signing in, pick a working folder and give the agent work that changes nothing: ask it to explain the entry points, the key modules, the verification commands and the risks. Such a request simultaneously exercises indexing, the agent, the terminal, and the fact that the working directory is the one you think it is. Each of those four can fail silently, and it is cheaper to find out on a task with no consequences.
The naive start looks different: open a large repository and immediately ask for something to be fixed. The temptation is understandable - you want to see an effect. But an agent allowed to change poorly understood code right away produces many edits quickly, along with a false confidence that it worked things out. Untangling such a diff costs more than spending one pass on a map of the project; and it makes it impossible to tell which of what you see is a property of the tool and which is a quirk of your repository. The first pass is valuable precisely because it gives you a baseline of behavior: until you have one, you will be explaining every oddity by guesswork.
It helps to see the wording of such a first request once. Below is exploration without changes: entry points and module boundaries, the install, lint, typecheck, test and build commands taken from the project files, the rules in force and AGENTS.md, three risks before the first edit - with an explicit ban on installing dependencies and touching the network. This form works for any new repository, not only for getting acquainted with Cursor.
Banning dependency installation in the first request is not over-caution. Installing changes the state of the machine, pulls the network and can take minutes, and its result adds nothing to understanding the project. The same goes for network commands: they turn deterministic exploration into a dependency on the outside world, where the answer depends on what someone else's server returned today. The first pass should read rather than change - then its result is reproducible and can be compared with what you get tomorrow.
The answer to such a request is verified rather than taken on faith, and the verification is cheap. Commands the agent presented as project commands must exist in the project files - open the manifest and compare the names. The entry points it named must be found at the paths it gave. If a command looks plausible but is not in the project, you have met the tool's most important property: it can confidently offer the typical in place of the actual. Noticing that on a harmless request is more useful than noticing it on an edit, where the same guessing goes straight into the code.
Exploration without changes has a limit of applicability. On a large repository a request to explain everything at once returns exactly what was asked for - a general overview from which not a single concrete decision can be drawn. The context is bounded, and the wider the question, the higher the level of generalization in the answer. The working form is different: name the subsystem, name the scenario and ask to be walked through it from entry to result. The sign that the question was too wide is recognizable at once: the answer contains not a single file name you could open.
Privacy Mode needs to be understood on its own terms. It governs how your data is processed and may be enforced across an organization. But it must not be confused with a permission policy: privacy answers the question of what happens to data on the service side, not the question of what the agent is allowed to do on your machine. A local terminal, a connected MCP server or a Cloud Agent operate within their own tools regardless of the privacy setting, and privacy being on does not stop a command from reading a file it has access to.
If you bring your own model key, a third party joins the picture. In that case the storage and processing terms are also set by your contract with the chosen model provider, not only by Cursor's settings. This is worth establishing before fragments of closed source start flowing through the agent: privacy here is the sum of several agreements, and the weak link is not determined by what the interface says.
A good first task is small, visible and easy to verify: fix some copy, add a test for behavior you already understand, update local documentation. You do not begin an acquaintance with a bulk migration, a deploy or a data deletion - not because the tool cannot handle it, but because you do not yet know how it behaves and cannot tell normal from dangerous. The selection criterion is simple: the result must be such that you can say "correct" or "incorrect" within a minute without launching an investigation.
The typical failures of a first session are predictable. Starting with a broad edit on unfamiliar code and getting a diff with nothing to check it against. Confusing Privacy Mode with permissions and deciding that privacy closes off tool access to data. Forgetting the provider's terms when using your own key. And spending the first pass on installing dependencies instead of on a map of the project.
Explore the repository without changes. Show:
1. the main entry points and module boundaries;
2. the install, lint, typecheck, test and build commands from the project's files;
3. the applicable rules and AGENTS.md;
4. three risks before the first edit.
Do not install dependencies and do not run network commands.