Opening an unfamiliar repository means trusting more than its source code. Executable scaffolding arrives with it: editor tasks, terminal profiles, hooks, MCP configuration, worktree setup scripts and package manager lifecycle scripts. All of it was written by someone else and runs on your machine with your rights. The difference from source code is fundamental: code has to be called to execute, while the scaffolding fires on its own - on opening the project, on opening a terminal, on installing dependencies. Workspace Trust exists precisely so that this decision is made deliberately rather than by the momentum of a click.
The naive attitude is understandable: there is no trust dialog by default, so nobody remembers the boundary at all. The mechanism stays off until it is enabled in the settings, and only then does opening a new workspace offer a choice between the normal and the restricted mode. The cost of that inattention is not visible at once and shows up on someone else's repository - cloned to check something, downloaded from an issue, sent over by a contractor. In restricted mode the AI features stop working, and for an unfamiliar repository the documentation plainly advises using an ordinary text editor instead; but it is exactly that boundary which separates reading someone else's code from executing someone else's configuration. The restriction here is not a punishment but a direct consequence of trust being granted to a whole workspace at once rather than file by file.
The other half of a safe start is the state of git. Before the agent begins changing files, it is worth looking yourself at what is already modified, which branch you are on, which worktrees exist and where the remote points. That is cheap insurance: a clean starting point turns any later diff into a meaningful picture, while a dirty one turns it into a puzzle where your edits are mixed with the agent's. The remote is checked for the same reason: a branch with a familiar name behaves identically in a fork and in the main repository right up to the moment you try to push.
It helps to see this minimum as commands once. Below are a short git status, the list of remotes and the list of worktrees. You come back to them before every meaningful task, not only when getting acquainted: three lines take seconds and remove a whole class of later questions about who changed what.
Workspace trust is easy to confuse with the run mode, and they are different axes. Workspace Trust answers whether the configuration that arrived with the repository may be executed at all. The run mode answers a different question: what the agent is allowed to do inside a project that is already open and already trusted. Neither substitutes for the other. A trusted workspace plus a wide run mode is two restrictions lifted in a row, and they are usually lifted at different times for different reasons, with nobody noticing that together they give the agent noticeably more than either concession implied on its own.
Checkpoints deserve to be understood separately. Cursor saves local snapshots of modified files before significant agent edits, and that is convenient: a bad step is undone inside the work instead of becoming a rescue operation. But a checkpoint is a mechanism for undoing agent changes, not a history system. Git remains the place where branches, review and collaboration live; relying on snapshots as a substitute for a commit means discovering one day that there is nothing left to roll back to.
From this follows a hard rule about a dirty tree. If the working copy holds uncommitted changes - someone else's or your own from before - the agent must not be allowed to tidy up. The correct request is to show git status, separate out what existed before the task and explicitly leave it alone: do not revert it, do not reformat it, do not include it in a commit. The most galling loss in agent work is not broken code but neatly cleaned-up uncommitted work that exists in no history and cannot be restored from anywhere.
When the dirty tree cannot be cleared, a separate checkout helps. A worktree gives the agent its own working copy of the same repository: the same history, a different directory on disk. Your uncommitted changes stay where they were, the agent works in its own tree, and the two physically cannot collide. The price is honest - the separate directory has to be prepared, dependencies installed in it again, and the result carried back through branches. The technique earns its keep on a long task or when several run at once, but for a short edit on a clean tree it is an extra step.
The first controlled edit is worth running against a short checklist: git status checked before the agent starts, the task limited to one observable behavior, the diff reviewed file by file rather than through the summary message, the project's existing checks run, and git status after them containing only the expected changes. Five items, each answering a question that otherwise gets asked after the trouble.
The typical failures at the start are predictable. Confirming trust for an unfamiliar repository without looking and getting someone else's hooks and MCP into your environment. Starting an edit on a dirty tree and losing the boundary between yours and the agent's. Mistaking a checkpoint for a commit. And judging the result by the agent's closing message instead of reviewing the diff file by file.
# A dirty tree: do not let the agent tidy up what is not its own
Show git status and separate the changes that existed before this task.
Do not revert them, do not reformat them and do not include them in a commit.# State before starting the agent
git status --short --branch
git remote -v
git worktree list