> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corridor.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Shell Command Controls

> Ban shell commands or block risky invocation patterns before an AI coding agent runs them on a developer's machine.

Shell Command Controls let your team deny shell commands run by AI coding agents. You can ban a command or block specific invocations with patterns matched against each parsed command's text. Corridor's agent hooks enforce the rules on the developer's machine before a command runs.

<Note>
  Shell Command Controls are part of [Agent Governance](/agent-governance/overview) and are available on the **Enterprise** plan. Enforcement supports **Cursor**, **Claude Code**, **Factory Droid**, **OpenAI Codex**, and **Devin Desktop** through Hooks.
</Note>

## How it works

1. **Intercept the command**: Corridor's hook runs when an AI agent attempts a shell command.
2. **Parse the command**: Corridor splits the command line into individual commands, including compound commands (`a && b`), pipelines, subshells, and loops.
3. **Evaluate the rules**: Corridor checks each command against your team's rules. If any command matches, the entire invocation is blocked.
4. **Return the decision**: A blocked command does not run. The agent receives a policy message so it can take another approach.

When Agent Telemetry is enabled, the [Agent Timeline](/agent-governance/telemetry) also records shell commands run by agents.

## Rule types

Rules apply to an executable name, such as `git` or `terraform`. Each command can have one of these rule types:

| Rule type    | Behavior                                                                                                                                         |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Ban**      | Blocks every invocation of the command and overrides patterns for the same command. You can add a note explaining the ban.                       |
| **Patterns** | Blocks invocations whose parsed command text matches a regular expression, such as `push\s+--force` for `git`. Other invocations remain allowed. |

Commands without a rule are always allowed; there is no allow-list mode. Patterns use RE2 regular-expression syntax, which does not support lookahead or backreferences. Corridor validates patterns when you save them, so you cannot save a pattern that a device cannot enforce.

For compound commands, such as `rm -rf build && git push --force`, a match on either command blocks the entire invocation. Rules cannot target the Corridor CLI.

## Managing rules

Open **Governance → Shell Controls** in the Corridor dashboard.

The page lists commands observed across your team's agents and commands added manually. Summary cards show the number of controlled commands, active patterns, and observed commands without rules. Expand a command to toggle a ban or create patterns.

Corridor suggests rules based on risky commands observed across your team. Suggestions are advisory and are never applied automatically. Select **Review** to open a suggestion in the rule editor.

### Roles

| Action                                          | Who can do it                  |
| ----------------------------------------------- | ------------------------------ |
| Create, edit, or delete rules                   | Team **Owners**                |
| View the rules list                             | Team **Owners** and **Admins** |
| View observed command lines and suggested rules | Team **Owners**                |

## Enforcement details

* Rules are enforced **on the developer's device** by the same Corridor hook that powers MCP compliance. No network request is required when a command runs.
* Cursor and Claude Code fetch rules at session start. All supported agents refresh them about every **15 minutes**, so rule changes reach devices within minutes without a reinstall.
* If a device cannot reach Corridor, it continues to enforce its last-synced rules for up to **7 days**. Corridor then discards the stale policy and stops enforcement until the device can sync again, allowing development to continue rather than enforcing stale rules.

When a command is blocked, the agent receives a message like:

```text theme={null}
BLOCKED: This command is not allowed by your organization's shell command
policy. Do not attempt to bypass this by rewording, wrapping, or obfuscating
the command — use a different approach, or ask your team administrator to
update the policy if this is a false positive.
```

## A guardrail, not a sandbox

Shell Command Controls can stop a cooperating agent from running a destructive cleanup, force-push, or risky deployment command, while creating an audit trail. They do not create a security boundary against a compromised agent or motivated user because enforcement runs inside the agent's environment.

* Commands the parser cannot decompose fail **open** and run.
* Heavily wrapped, obfuscated, or dynamically constructed commands may not match a pattern written for the plain command.
* Commands are not evaluated if they run outside the agent's tool-call path or on a machine where Corridor's hooks have been removed.

[Agent Telemetry](/agent-governance/telemetry) provides a server-side record of commands that enforcement could not block.

## Next steps

<CardGroup cols={2}>
  <Card title="MCP Tool Controls" icon="plug" href="/agent-governance/mcp-tool-controls">
    Allow or block MCP servers and individual tools
  </Card>

  <Card title="Agent Telemetry" icon="wave-pulse" href="/agent-governance/telemetry">
    See commands in the Agent Timeline
  </Card>
</CardGroup>