feat(tui): auto permission classifier - a middle tier between build and yolo

[wesleymatosdev]

feat(tui): auto permission classifier — a middle tier between build and yolo

Why

Claude Code ships an auto permission mode: a classifier answers most prompts automatically and only escalates the gray zone to the user. ZCode's terminal client currently offers only two poles — build (prompt for everything) and yolo (prompt for nothing). The runtime reserves an auto mode value but currently denies all tools in it (Auto mode is reserved but not implemented yet), so there is no way to run "safe things automatically, ask me about the rest."

This PR adds that middle tier in the TUI, where the permission UX lives, without touching the vendored runtime.

What it does

Classifier at the dialog seam. requestToolPermission() consults a static policy before rendering the choice dialog:

• allow — read-only shapes: git status/log/diff/show/branch, ls, pwd, cat, head, tail, wc, rg, grep, find, which, file, stat, plus the Read/Glob/Grep/TodoRead/WebSearch tools
• deny (with reason) — rm -rf, sudo, curl|sh, git push --force, git reset --hard (soft), and credential paths (.env, .ssh, .aws, .gnupg, .kube, .netrc, .npmrc, *.pem, id_rsa, …) even for reads
• unmatched — null → the normal human dialog, unchanged

A verdict returns the same response object the dialog returns ({ decision, reason }), so runtime semantics are untouched. Every auto-decision prints a transcript notice (auto-permissions · ALLOW · Write · …) so users can always see what was decided and why.

Opt-in auto client mode. Shift+Tab and the /mode picker now cycle a client-side list — build → edit → auto → yolo → plan. Selecting auto pins the runtime to build (so prompts still reach the client) while the footer shows auto and the classifier decides prompts. Typed /mode commands still execute in the runtime (which owns its enum) and exit the overlay. One-shot runs can boot into the overlay with ZCODE_CLIENT_MODE=auto, honored only over a build runtime.

Policy is data. ZCODE_AUTO_PERMISSIONS_CONFIG=<path> overrides the built-in rules point-wise (allow / softDeny / hardDeny rule arrays with tool, commandPrefix, commandRegex, pathPrefix, pathRegex, note; defaults.unmatched: ask|allow|deny). Malformed or missing files fall back to built-ins. Defaults are conservative: unmatched → ask.

Safety properties (structural, not disciplinary)

• Classification runs only where a prompt would have rendered — it cannot widen yolo or affect non-prompting paths.
• Runtime-side explicit deny rules never prompt, so they can never be overridden.
• AskUserQuestion and plan-approval flows are never auto-answered (explicit gate).
• Any internal error defers to the dialog — a broken policy cannot wedge a session into deny.

Testing

• test/auto-permissions.test.ts (8) — classification semantics, precedence, credential paths, config load/fallback, dialog-response mapping
• test/shortcuts-auto.test.ts (9) — client mode cycle (official modes/nextMode contract unchanged), runtime-vs-client normalization, boot gating, classification gate
• bun run typecheck clean; biome check clean on all touched files; full suite delta vs main verified zero (pre-existing env failures identical on a clean-main worktree)
• Live A/B against the real runtime over a PTY (isolated HOME, identical prompt, only the TUI bundle swapped): stock renders the write dialog and writes nothing; the patched client in auto prints the allow notice, executes the covered write with no dialog, and still renders the dialog for an uncovered write. This run also caught a real integration bug (runtime mode echoes clearing the overlay), now fixed and covered.