Permissions

Every tool action is checked against a ruleset whose effect is allow, ask or deny. Rules from the agent, from the repository and from your saved answers are merged: deny wins, then ask, then allow, and anything with no matching rule defaults to ask. An agent with no permissions at all is denied everything rather than trusted.

When you answer always, that allow is saved for the repository, so the same action is not asked again. Saved answers are per repository, and you can clear them.

For unattended runs the terminal agent takes --auto (also spelled --yolo or --dangerously-skip-permissions). It auto-approves anything not explicitly denied — deny rules still hold. It is off by default, and it is the flag to think twice about.

Repository trust

From desktop 1.99.108, a repository's own vector.json and .vector folder (its agents, commands, modes, plugins, tools, skills, MCP servers, formatters and language servers) load only after you trust the repository, because they can run code on your computer. Until then Vector applies the repository's deny rules, and its run limits, loop pauses and sharing settings only where they are stricter than yours, so a cloned repository cannot raise your spend cap or switch loop pauses off. From desktop 1.99.109, a repository's run limits are ignored even once you trust it, because spend limits are one overall set of yours, and Vector says so once for each repository file that still sets budget.run, not again for the repository's agent worktrees or copies.

From desktop 1.99.109, the app asks once, the first time you open a repository that has settings of its own: Trust this repository? Choose Trust this repository to load its settings as they are now, or Not now to leave them off, and the app does not ask about it again. Every such repository asks, including one you clone with Open from GitHub, because a clone can come from anyone's link. To trust one later, choose Trust this repository… in its menu on Home, or open Settings, Repository trust. Only you can trust a repository on your computer, so a guest you invite is never asked; the app tells the guest that you decide. In desktop 1.99.108 the same approval is the button in the session header. The TUI's /trust and the terminal's vector trust status and vector trust approve arrive with the next CLI release; the CLI that npm and vectordev.ai/install serve today has neither, and Windows WSL servers keep the 1.99.99 engine, without repository trust, until a later desktop release requires that CLI.

The language servers and formatters you turn on in your own settings also stay off in a repository you have not trusted, because they run its code, and your own local MCP servers start in an empty folder outside it, so the repository's node_modules, .npmrc or Python modules cannot take them over. This holds in a repository with no settings of its own too. The app does not ask about such a repository; while your tools are held back there it shows a Repository not trusted notice, and you trust it in Settings, Repository trust. Agent and parallel workspaces are folders of their own with their own trust: the question about one reads Trust this workspace?, and from one of their sessions Settings shows that folder beside the repository it came from.

Trust covers the repository as it was when you approved it. A later change to anything that can run, from a pull or an edit, needs approval again, and the app asks once more; plans, memory and rules that Vector writes into .vector do not. Integrations you add from the app are kept with your own settings rather than in the repository, so they stay after a restart. A trusted repository can add allow rules, but it cannot lift a deny in your own settings.

Read-only specialists

From desktop 1.99.108, the read-only specialists (explore, review and security) ask before they run a test or build command such as bun test, npm test, pytest, cargo test or go test, because those run the repository's own code. Approve once, or approve always for the rest of the session. In an unattended vector run they are refused unless you pass --auto, and git and pull request reads still need no approval. The terminal agent gets this with the next CLI release, and Windows WSL servers once a later desktop release requires that CLI.

Your own network

From desktop 1.99.108, when an agent's web fetch would reach your own computer or network (a dev server on localhost, an intranet page, a cloud metadata address), Vector asks for private_network as well as webfetch, so a hostile page cannot steer the agent into your network. Approve it once for that address, or allow it in your settings, for example "permission": { "private_network": { "http://localhost:3000": "allow" } }. Addresses you put in your own settings (remote instructions, skill catalogs, providers such as a LAN Ollama host, MCP servers, references) are reached without asking. The terminal agent gets this with the next CLI release, and Windows WSL servers once a later desktop release requires that CLI.

The shell sandbox

Commands an agent runs can be confined to their workspace by the operating system's own mechanism — a seatbelt profile on macOS, bubblewrap on Linux where it is installed — by setting VECTOR_SHELL_SANDBOX from 1.99.99. Releases before 1.99.99, such as desktop 1.99.8 and npm CLI 1.99.7, do not read that name, so setting it there confines nothing.

It is opt-in and off by default, and Windows ships no equivalent, so on Windows Vector reports that it is running unconfined instead of implying protection it cannot provide.