---
title: "Dangerous command interception"
description: "Commands that are clearly dangerous are refused outright."
lang: en
---

Beyond asking you every time, Bi intercepts a set of clearly dangerous commands and refuses them outright. This is a harder gate than approvals.

## What is intercepted

- Destructive commands, such as deleting files, pushing code or publishing
- Commands that change file permissions
- Using a shell for something a dedicated capability should do, such as reading, writing or searching files
- Unregistered plugin or capability names

These are built-in defaults and apply out of the box. You can add or remove rules in Settings.

## What happens on a match

The call is refused immediately — no confirmation dialog. The agent receives the reason and tries another approach.

Some rules can be set to “require confirmation” instead: a match raises a prompt, and the command runs only if you approve it on the spot.

## Relation to approval settings

Both gate operations, but differently:

- [Operations that need approval](/docs/configuration/permissions) raise a **confirmation dialog** you can approve
- **Intercept rules** refuse outright, with no confirmation step

They stack: an operation runs only if both allow it.

## A common misunderstanding

Intercept rules inspect command content. They **cannot** be used to restrict access outside the workspace. The workspace boundary is a separate mechanism that settings cannot relax. See [Workspace](/docs/using-bi/workspace).
