Before the first command in an unfamiliar repository there is a step easy to skip because it seems not to exist: the agent has already arrived with settings. Rules, skills, subagents, hooks, plugins and MCP servers load silently, from several sources at once, and start acting before you type a single word. The naive assumption is that all of this is "mine and harmless" since it is in my project. That assumption is exactly what makes the first run blind.
The assumption breaks on the fact that the loaded settings come from three different scopes with different accountability. The Customizations panel in Devin Local shows the actually loaded rules, skills, subagents, hooks, plugins and MCP servers and, crucially, where each of them comes from: from the repository, from the organization, or from your account. "From the repository" means anyone with access to the branch could have placed them. "From the organization" means they were pushed down by policy and you do not control them. "From the account" means they are your personal ones, traveling with you between projects. Three sources are three different answers to the question "who put this here".
Why this is worth looking at as a list rather than from memory. An always-on rule acts in every session without asking; a hook stands on the path of tool calls and runs code; an MCP server opens an external endpoint with permissions and data; a plugin brings all of the above at once. None of these influences announces itself at the moment of the first command - it is already on. The Customizations panel is a way to see what is on before it shows up in the agent's behavior, not after, while figuring out why it "on its own" did something.
Hence the practice: a project audit before the first command, over a few explicit points. Always-on rules should be short and not contradict one another - a long or conflicting always-on quietly distorts every session. Hooks should belong to the repository and have a clear outcome: what exactly they allow, change, or block. MCP endpoints and their scopes should be approved by you deliberately, not inherited. Plugins should be pinned by version and reviewed by composition. And separately: there should be no unknown imports from other AI tools that have slipped into the configuration.
The last point deserves separate attention, because it is a frequent and unnoticed source of foreign behavior. The configurations of different agent tools are similar in form, and a file brought over from another product can be picked up as "one's own", carrying rules and instructions you did not write and are not answerable for. The sign is simple: there is a line in the loaded list whose origin you cannot name. Until it is named, it is not your setting but an unknown acting with your permissions.
The cost of a skipped audit is concrete and always surfaces later. The agent "on its own" keeps a strange style - because someone else's always-on rule sits in the repository. A command "for some reason" is not carried out - because an inherited hook intercepts it. A call appears to an external service you never connected - because an MCP server arrived with a plugin or from the organization. Each of these cases is explained by one line in the panel that was not opened in time.
It also helps to understand the flip side: an audit is not a one-off installation procedure but a state that goes stale. Switching a branch can swap the project rules and hooks for others. Updating a plugin can bring new always-on instructions and new hook code under the same name. A change in enterprise policy can add or remove organizational settings without your involvement. So the audit is repeated after each of these events rather than considered closed once and for all.
You verify the result of the audit by a method other than a cursory glance: go down the list and for each line name the source and the purpose out loud or in a note. A line for which no answer to "who and why" is found is not a passed check but a discovered task. In stable 3.8.20 a common search works across the loaded settings, which makes such a pass quick even in a dense configuration. The audit is closed not when the panel has been viewed but when every active setting has a clear explanation.
The typical failure is treating the panel as informational rather than as a control. It is opened out of curiosity after the agent has already behaved strangely, and used for an after-the-fact explanation instead of a check beforehand. The second failure is running the audit once and considering it eternal, not repeating it after a branch switch or a plugin update. The sign of both is the same: the first command was handed to an agent whose loaded configuration was never named point by point. Name it before the command - and most of the "it did it on its own" simply will not arise.