You open an unfamiliar repository: a fresh clone, someone else's pull request, a downloaded template. The first urge is to open it like any other project and start working, with agents at the ready. But code you have not yet read is not only text you will look at; part of it can execute on its own, even before you have decided anything.
The naive move is to trust the repository by the mere fact of opening it: agents on, hooks loading, tasks and recommendations picked up automatically, because it is convenient and it has always been so with your own projects. With your own, trusted code that is indeed the norm. The mistake is carrying the same ease over to code whose origin you have not checked.
It breaks on the fact that a repository can carry executable content. Hooks, tasks, extension recommendations, scripts, MCP configuration, submodules, unexpected binaries - none of this is passive text, but things that, on an ordinary opening of the project, can run. An agent or a hook triggered on untrusted content is code execution you have not audited, on your machine and under your permissions.
The professional mechanism against this is Restricted Mode. In stable 3.7.16, when a workspace is open in this mode agents are unavailable in it: Cascade, Devin Local and every ACP agent are disabled, and hooks neither load nor run. Agents become available again as soon as the workspace leaves Restricted Mode. In essence it is a hard off-switch for the whole agentic layer for as long as trust in the code is not yet established. Nothing starts automatically: neither an agent at your command nor a hook on a file event, while the mode is on.
Why this is made a switch of the environment rather than a rule in the prompt. An instruction to "be careful with unfamiliar code" an agent can interpret and get around - it remains text that it itself reads. Restricted Mode does not ask the agent to behave carefully; it does not let the agentic layer start at all. The safety here is that nothing runs, not that something runs carefully. This is the same principle as a sandbox and a permission deny: protection by means of the environment, not trust that the text will be interpreted correctly.
This protection has a cost, and it is a deliberate cost. In such a workspace you lose autonomy: while the mode is on, you have to work by hand, without delegating to an agent. But this is not a defect, it is the very point of the mode - to trade convenience for the guarantee that untrusted code will not start acting on your behalf before you have studied it. In an unfamiliar repository this loss of autonomy is temporary - it is lifted exactly when the unknown is lifted.
You should not lift the restriction just for convenience. Before leaving Restricted Mode, check the repository's source and what in it is capable of executing: tasks, extension recommendations, scripts, hooks, submodules and unexpected binaries. The point of the pause is precisely to separate reading the code from running it - first you understand what is in front of you, and only then do you allow it to work. Special attention goes to the places that execute without your explicit call: a hook event, an auto-task, an extension recommendation, an install script.
You must verify the result of lifting the restriction with a separate look. Having left the mode, open Customizations and see what actually loaded: which rules, hooks, MCP and subagents activated along with trusting the project. This is the same principle as with subagent profiles: allowing and seeing what exactly was allowed are different steps, and the second must not be skipped. The list of what loaded is the map of what you have just trusted - you check against it whether anything extra appeared.
The engineering conclusion is simple and symmetric to the cost. Default-deny for untrusted code is cheap - it costs you minutes of manual work and one check. Dealing with the aftermath of an unaudited hook that already ran is expensive and not always reversible. Restricted Mode moves the cost from an unpredictable "after" to a predictable "before", and that is its entire value. The cheapest way to enter unfamiliar code is exactly this: first deny, then read, and only then allow.
The typical failures are predictable. The first is reflexively lifting the mode so it "does not get in the way" and launching the agentic layer on code that was never read. The second is inspecting only the visible code and missing exactly what executes on its own: hooks, tasks, extension recommendations. The third is deciding that since the agents were disabled everything else is safe, and not checking what loaded after leaving the mode. The sign of all three is the same: trust was granted by the fact of opening rather than by the results of checking what this repository is capable of executing.