---
title: CLI commands
description: Every subcommand rippy ships with, grouped by what it's for.
---
Most of the time you'll invoke rippy as a hook — `rippy --mode claude` or
similar — and the rest of the machinery is invisible. But rippy also has a
handful of subcommands for setting up, inspecting, and evolving your
config. Here's the full list.
## Running as a hook
| `rippy --mode claude` | Run as a Claude Code `PreToolUse` hook (reads JSON from stdin, returns verdict on stdout) |
| `rippy --mode cursor` | Run as a [Cursor](/getting-started/cursor/) hook |
| `rippy --mode gemini` | Run as a [Gemini CLI](/getting-started/gemini-cli/) hook |
| `rippy --mode codex` | Run as a [Codex CLI](/getting-started/codex/) hook |
## Setup
| `rippy init` | Initialize config with interactive package selection |
| `rippy init --package <name>` | Initialize with a specific [package](/getting-started/packages/) (`review`, `develop`, `autopilot`) |
| `rippy setup claude-code` | Install rippy as a hook for Claude Code |
| `rippy setup gemini` | Install rippy as a hook for Gemini CLI |
| `rippy setup cursor` | Install rippy as a hook for Cursor |
| `rippy setup tokf` | Configure [tokf](https://github.com/mpecan/tokf) to use rippy as its permission engine |
## Packages and profiles
| `rippy profile list` | List available safety packages (built-in + custom) |
| `rippy profile show <name>` | Show what a package auto-approves, asks, and blocks |
| `rippy profile set <name>` | Activate a safety package |
`<name>` accepts any built-in (`review`, `develop`, `autopilot`) or a
custom package discovered in `~/.rippy/packages/<name>.toml`. See
[Custom packages](/getting-started/packages/#custom-packages) for how
to author one.
## Inspect and debug
| `rippy inspect` | Show all configured rules |
| `rippy inspect <command>` | Trace the decision rippy would make for a specific command |
| `rippy debug <command>` | Trace the full decision path (every rule considered) for a command |
| `rippy list safe` | List all auto-approved safe commands |
| `rippy list handlers` | List commands with dedicated handlers |
| `rippy list rules` | Show effective rules merged from all config sources |
| `rippy stats` | Show aggregate decision-tracking statistics |
## Evolve your config
| `rippy allow <pattern>` | Add an `allow` rule to your config |
| `rippy deny <pattern>` | Add a `deny` rule to your config |
| `rippy ask <pattern>` | Add an `ask` rule to your config |
| `rippy suggest` | Analyze your tracking data and suggest new rules |
| `rippy discover <cmd>` | Discover flag aliases from a command's help output |
| `rippy migrate` | Convert a legacy flat `.rippy` config to `.rippy.toml` |
## Trust and safety
| `rippy trust` | Manage trust for project-level config files (see [Configuration overview → Project config trust](/configuration/overview/#project-config-trust)) |
## Tips
- `rippy inspect <command>` is the fastest way to answer "why did rippy
block / approve / ask about this?" — it reports which rule fired and
which config file it came from.
- `rippy suggest` pairs well with `rippy stats`: let rippy watch your
sessions for a while, then ask it which rules would have saved you
approval prompts.
- `rippy migrate` is a one-shot converter for the legacy flat
`.rippy` / `.dippy` format. Write new configs as `.rippy.toml`; the
flat format stays loaded for backward compatibility.