orcalisted

# Orca Guardrails For Pi Orca evaluates Pi tools before they run: | Tool | Path | |------|------| | `bash` | daemon Evaluate (`orca evaluate --json --stdin`, `source.host=pi`) | | `write` / `edit` | Zig `orca decide file` with `operation: write` | | `read` | Zig `orca decide file` with `operation: read` | | `grep` / `find` / `ls` | Root preflight plus explicit approval; descendants are not individually evaluated | | Any other tool name (custom / MCP-shaped) | Zig `orca decide tool` with `{"name":"<toolName>"}` (name only) | Custom/MCP-shaped tools are **name-gated** via `decide tool` — this is **not** full MCP protocol mediation or an MCP proxy. Treat an Orca block as a security decision, not as a formatting problem to route around. `grep`, `find`, and `ls` remain approval-gated even when the root preflight allows them. Do not describe a broad root check as proof that every traversed file is safe. **Process-level env/network/secretless** are **not** provided by the extension alone. Launch Pi under Orca: ```bash orca run -- pi orca run --secretless --network ask -- pi ``` Install: `pi install npm:@orca-sec/pi-orca`. Do not mix that with `pi install ./orca-pi`. When Orca blocks a command or file action: - Explain the block reason to the user without restating sensitive command or path contents. - Surface the **rule id** when present (decision cards include `rule …`). - Ask the user how they want to proceed. - Do not bypass Orca by obfuscating, splitting, encoding, rewr