Approvals & safety

Interactive approval

When a tool needs confirmation:

Press [y] Allow once | [s] session | [p] project | [g] global | [n] Deny

Key	Scope	How long
`y`	This call only	once
`s`	This session	about 30 minutes
`p`	This project	about 30 days (saved under `.ninja/`)
`g`	Global	about 30 days (saved under your config dir)
`n`	Deny	—

Many read-only shell commands auto-approve. Changes usually prompt. Approval keys work when the chat input is empty.

Less prompting (use carefully)

**Shift+Tab** — auto-approve for this session (still careful about shell outside the project).
**--dangerously-permissionless — skip interactive confirms from startup. Not a sandbox.**

Policy preview

ninja policy check "git push --force"

Shows whether a command would be allowed, confirmed, or refused. Handy before headless runs.

Always-blocked patterns

Some destructive or hard-to-analyze shell patterns are always refused, even with --yes or permissionless mode (including common wrapper prefixes like sudo). Use ninja policy check to see the verdict for a specific command.

Headless

ninja -p "..."            # strict: anything that would need confirm is rejected
ninja -p "..." --yes      # auto-approve within policy

Safety-net, not a sandbox

--yes does not isolate disk or network. Never use it on untrusted prompts.

File & MCP tools

Edits and MCP calls use confirmation and trust lists. They are not the same path as shell policy checks.