Permissions

Set a clear working scope

Select the project, files, and external target needed for the task. Describe the permitted result and any boundaries that must remain unchanged. A project selection is a working location, not authority over the whole device.

Read-only planning, review, and diagnosis do not authorize file writes. Implementation and repairs require the applicable write and command scope. An empty file scope does not grant repository access.

Use a narrow scope for an unfamiliar project or integration. Expand it deliberately when the next required action is clear.

Review an approval request

Read the action, exact target, and intended effect before responding. Approve it only when it matches the work you asked for. Reject it to prevent the pending action, or stop the task to end the current work.

• Check the file or folder and whether it will be read, changed, or removed.
• Check the command and the environment where it will run.
• Check the account, website, recipient, or publication target.
• Treat payment, deletion, access changes, and external messages as consequential actions.

A permission decision applies to the task and action it describes. It is not an unrestricted approval for unrelated work. Operating-system permission prompts are separate from the task’s permissions.

Separate availability from authority

Enabling Browser Use, an MCP server, or a skill makes that capability or guidance available. It does not authorize every action the tool supports. Account permissions, task scope, and the tool’s own connection state still apply.

Review external MCP server commands and destinations before connecting them. A local server runs software on your device; a remote server receives the content sent through its tools.

Turning a capability off prevents its continued use. Turning it back on does not restore authority from a canceled task; start again with the appropriate task setup.

Manage tools and plugins

Understand rejection, cancellation, and recovery

Rejecting a request prevents that pending action. Stopping ends ongoing work, but it does not undo completed edits, sent messages, purchases, or other external effects.

Inspect the latest task status and existing results before retrying an interrupted operation. If an outcome is uncertain, establish whether it happened before repeating it.

Keep your own backups and review diffs before applying changes. Permissions reduce the scope of an action; they do not replace verification of its result.

• Previous Search & sources
• Next Tools, skills & plugins