pi-nolo

内容来源:README.md(说明文档) · 原始地址 · 查看安装指南

原始内容

pi-nolo

No-YOLO mode for pi-coding-agent. Gates write, edit, and bash tool calls behind user confirmation — press Enter to allow, Escape to block.

Read-safe bash commands (ls, grep, git status, etc.) are auto-approved via a configurable allowlist, so you only get prompted for commands that could mutate state.

Install

pi install npm:pi-nolo

Or from git:

pi install https://github.com/burneikis/pi-nolo

Note:

The default YOLO-cycle shortcut is ctrl+y, which conflicts with pi's built-in tui.editor.yank. Instead of editing pi's keybindings.json, you can move the extension's shortcut by setting "shortcut": "ctrl+shift+y" in your nolo.json (see Configuration). Changing it takes effect after a /reload.

What it does

Every time the agent tries to:

  • Write a file — confirms with the file path and line count
  • Edit a file — confirms with the file path; shows a pre-rendered diff preview before the tool finishes executing
  • Run a bash command — auto-approves safe read-only commands; confirms everything else

You get a dialog: Enter to allow, Escape to block.

In non-interactive mode (no UI, e.g. pi -p or --mode json) nothing is gated by default, since there is no way to confirm. Enable strict non-interactive mode to instantly block anything that would have required confirmation instead:

  • Config: set "strictNonInteractive": true in nolo.json (project overrides global).
  • Env var: NOLO_STRICT=1 (or true) enables it, NOLO_STRICT=0 disables it; the env var overrides config.

With strict mode on, write/edit calls and non-read-only bash commands are blocked with a clear reason; safe read-only bash commands still run. Example:

NOLO_STRICT=1 pi -p "Review the code in src/"

Pre-rendered edit diffs

As of pi ~0.63.0, the built-in edit tool only shows diffs after execution. This extension includes a built-in pre-renderer (ported from pi-pre-render-edit) that computes and displays the diff as soon as the tool arguments are complete -- before the edit is applied. This means you can see exactly what will change while the confirmation dialog is open.

If you previously installed pi-pre-render-edit separately, you can remove it -- the functionality is now bundled here.

YOLO modes

Use /yolo to cycle through three modes at any time during a session:

Mode Footer label Write/Edit Bash
off (default) nolo confirm confirm (safe cmds auto-approved)
writes writes auto-allow confirm (safe cmds auto-approved)
full yolo auto-allow auto-allow

Each /yolo invocation advances to the next mode and wraps back around:

off → writes-yolo → full-yolo → off → …

The current mode is shown in the footer status bar. It is also persisted in the session so it survives a /reload.

When to use each mode

  • writes — you trust the edits but still want a gate on shell commands.
  • full — you want the agent to run completely hands-free. Use with caution.

Scope writes to the project root

In writes mode, write/edit calls are normally auto-approved anywhere on disk. Scope-writes narrows this: when on, writes mode still confirms any write/edit whose path resolves outside the project root (cwd), so the agent can't silently edit files elsewhere. off and full modes are unaffected.

  • Config default: set "defaultScopeWrites": true in nolo.json (project overrides global overrides the built-in default of false).
  • Toggle live: run /scopewrites at any time during a session to flip it. The choice is persisted in the session so it survives a /reload.
scope-writes writes mode write inside root writes mode write outside root
off (default) auto-allow auto-allow
on auto-allow confirm

Bash Command Allowlist

Safe commands are auto-approved without a confirmation dialog. A command is considered safe when:

  1. Every shell segment starts with a recognized safe prefix (e.g., ls, grep, git status)
  2. It does not contain dangerous constructs, flags, redirects, or mutation forms
  3. Any command substitution is recursively safe and is not supplying an opaque argument to a command whose flags can write or execute

Default safe prefixes

cd, ls, cat, head, tail, wc, find, grep, rg, fd, tree,
file, stat, du, df, which, whoami, pwd, echo, date, uname,
printenv, basename, dirname, realpath, readlink, id, hostname,
md5sum, sha256sum, git status, git log, git diff, git show,
git blame, git ls-files, git branch, git remote, git tag,
git rev-parse, npm list, npm outdated, npm view, node --version,
python --version, cargo --version, rustc --version, go version,
sed, true, false, :, sort, uniq, cut, tr, jq, column, paste,
comm, diff, less, more

sed

sed is allowlisted but gated behind a strict read-only script grammar rather than a flag blacklist, because its script language can write files (w, W, s///w) and run commands (e, s///e) even without -i. A sed segment auto-approves only when every script (positional or via -e/--expression) consists of numeric or $ (last-line) addresses with the p, d, =, or q commands, and every flag is from the read-only set (-n, -u, -z, -s, -E, -r and their long forms). So sed -n '2400,2480p' file and sed 10q file auto-approve, while sed -i, -f, s///, w/e commands, regex addresses, backslash escapes, and options appearing after filenames (GNU sed permutes arguments) all prompt.

Dangerous pattern guard

Even if a command starts with a safe prefix, it will still require confirmation if it contains:

  • Backtick command substitution (`)
  • $() command substitution whose inner command is not itself safe
  • Redirections (>, >>)
  • Dangerous commands (rm, sudo, eval, exec, source, sh, bash)

For example, ls is auto-approved but ls; rm -rf / will prompt for confirmation.

Variable assignments

Standalone assignments with literal values are treated as safe segments, and $NAME / ${NAME} references to them are expanded before prefix matching. So D=/some/dir; $D/tool.sh is judged exactly like /some/dir/tool.sh. Values containing quotes or spaces are not recognized as assignments, and unknown variables are never expanded (such commands fall through to confirmation).

cd tracking

cd <literal-dir> targets are tracked so that a following relative command word (./x, ../x) can be resolved to an absolute path before prefix matching: cd /skills/phab/scripts && ./tool.sh is judged exactly like /skills/phab/scripts/tool.sh. The tracked directory always survives && boundaries, where the shell guarantees the cd succeeded in the main shell. It also survives ; and bare-newline boundaries when the target directory is verified to exist (and be traversable) at check time -- a verified cd cannot fail, so the later segments really do run there. | and || always invalidate the tracked directory: a subshelled or conditionally-skipped cd leaves ./x pointing at a different, untrusted file regardless of the filesystem. cd targets containing variables, substitutions, quotes, or ~ are never trusted.

Bare newlines are treated as command separators (like ;) and each line is checked independently; backslash-newline continuations are joined.

Command substitutions

$(...) substitutions are not executed by the checker. Their inner command text is validated recursively, then replaced with an inert placeholder solely for static matching. So WEEK=$(date +%s); echo $WEEK auto-approves, while echo $(curl http://x) confirms. A substitution used as the command word itself always confirms.

Although shell operators in substitution output are not re-parsed, the output can become command options. Built-in prefixes whose options can write or execute (find, fd, sort, rg, date, selected Git commands, etc.) therefore reject opaque substitution-derived arguments: sort $(echo -o) ... confirms. Custom safe prefixes are treated as an explicit assertion that their complete argument surface is safe; wrappers should enforce their own read-only operation guard, as the Phab search wrapper does. Backticks, unsafe/unbalanced/empty substitutions, and arithmetic expansion $((...)) always confirm.

Configuration

You can customize the allowlist with a nolo.json config file:

  • Project-level: .pi/nolo.json (takes precedence)
  • Global: ~/.pi/agent/nolo.json

Config format

{
  "safePrefixes": ["make build", "docker ps", "kubectl get"],
  "dangerousPatterns": ["\\|", "&&", "\\brm\\b"],
  "shortcut": "ctrl+shift+y"
}

Merge behavior

  • safePrefixes — merged (union of defaults + global + project)
  • dangerousPatterns — overridden (project overrides global overrides defaults)
  • shortcut — overridden (project overrides global overrides default)

If no config files exist, the hardcoded defaults are used. See nolo.example.json for the full default configuration.

Example: add custom safe commands

Create .pi/nolo.json in your project:

{
  "safePrefixes": ["make build", "docker ps", "kubectl get pods"]
}

These will be added to the defaults — you don't need to re-list the built-in prefixes.

Example: relax dangerous patterns

If you want to allow piped commands (at your own risk):

{
  "dangerousPatterns": [
    "&&",
    "\\|\\|",
    ";",
    "`",
    "\\$\\(",
    ">\\s",
    ">>",
    "\\brm\\b",
    "\\bsudo\\b",
    "\\beval\\b",
    "\\bexec\\b"
  ]
}

This replaces the defaults entirely, so the \\| (pipe) pattern is no longer checked.

Example: change the YOLO-cycle shortcut

The shortcut field sets the key that cycles YOLO mode. It defaults to ctrl+y, which collides with pi's built-in tui.editor.yank. To avoid the conflict without touching pi's keybindings.json, pick another key:

{
  "shortcut": "ctrl+shift+y"
}

The shortcut is resolved once when the extension loads, so changes take effect after a /reload. The /yolo slash command always works regardless of the configured shortcut.

License

MIT