Bash permissions

bash runs all shell command strings inside the workspace, including tests, lint, typecheck, builds, checks, and smoke scripts. Unknown commands require interactive approval unless project or user config allows the exact command or a prefix under tools.bash.

{
  "tools": {
    "bash": {
      "allowExact": ["pnpm check"],
      "allow": ["pnpm test", "mise run"],
      "deny": ["pnpm publish", "npm publish"],
    },
  },
}

allowExact matches a complete command string. allow and deny match either that complete string or the string followed by a space and more arguments. For example, "pnpm test" also allows pnpm test test/tools.test.ts, but it does not allow pnpm test:watch. Deny rules win.

Interactive approval can run a command once, allow that exact command for the session, or save that exact command for the repo. Add an allow rule to config when a trusted command prefix must accept changing arguments.

Use project config for commands that are safe and expected in the repo. Keep broad permissions out of shared config unless the whole team accepts that policy.

For benchmark or automation runs, topchester run --dangerously-auto-approve can auto-approve approval-required bash prompts without adding allow rules to topchester.jsonc. This runtime mode does not bypass deny rules, destructive command detection, workspace boundary checks, or hook blocks.

Terminal-Bench runs should use topchester run --dangerously-auto-approve --benchmark-profile terminal-bench. That explicit benchmark profile keeps configured bash deny rules, but allows broad shell commands inside the disposable benchmark container and treats successful bash work as valid task-change evidence for non-code tasks.