Classifier-backed permission mode ("auto") between auto-accept and bypass (yolo)

[robertor4]

Feature Description

Summary

Add an opt-in permission mode in which tool calls the rule engine leaves unresolved are judged by a model rather than falling through to a prompt. Today those calls always land on rung 13 (ASK), which is the mode's whole ceiling: auto-accept can only skip prompts for the operation classes hardcoded into its fast path.

Motivation

The current five modes are well designed and the ordered ladder is genuinely nice to reason about. But there's a real gap in the middle of the range for long unattended-ish sessions:

• auto-accept covers workspace edits plus a fixed list of safe filesystem commands (mkdir, touch, cp, mv, non-recursive rm, rmdir, sed). Everything else — npm test, pytest, cargo build, go vet, docker compose up, tsc --noEmit, gh pr view — is "other mutating shell" and prompts. On a 40-minute refactor that's dozens of interruptions for commands that were never risky.
• The fix is allow rules, but that means enumerating your toolchain in advance, per project. It works for the commands you predicted and does nothing for the ones you didn't. New repo, new stack, new script in package.json → back to prompting.
• dont-ask has the same enumeration problem with worse ergonomics for interactive use: it fails closed, which is correct for CI and wrong for a person sitting at the terminal.
• bypass is the only escape and it's the wrong shape — it's --yolo, launch-only, throwaway-environments-only, and deliberately so.

So the practical choice on a normal repo is "approve a lot of prompts" or "turn approvals off." A classifier fills that gap: it can approve npm run test:watch on its merits without anyone having written Shell(npm run *) first, while still stopping on the thing that would have been stopped anyway.

Proposal

A sixth mode, auto, that inserts one rung into the existing pipeline and changes nothing above it.

Placement in the ladder

Insert between rung 12 (accept-edits fast path) and the terminal ASK:

  11  allow rules ──────────► ALLOW
  12  auto-accept + in ws? ─► ALLOW
  12a auto mode? ───────────► classifier: ALLOW | ASK | DENY
          │
          ▼
      ASK   (DENY in dont-ask)

This placement matters and I'd argue it's the only defensible one:

• deny and ask rules (rungs 1–2) still win. A user's explicit rule is not a suggestion to a model.
• The external-directory gate, the plan-mode gate, the root/home circuit breaker and the sensitive-write gate all sit above it and are untouched.
• The classifier only ever sees calls that were already headed for a prompt. Worst case it makes a call that would have been a prompt into a DENY or an ALLOW; it can never widen anything a rule had already resolved.

Put another way: this is not a replacement for [design decision #1](https://commandcode.ai/docs/permissions#design-decisions) ("rules over a hardcoded safety matrix"). It's a policy for the unresolved set, which today has exactly one policy — always ask.

Config

Reuse the existing permissions block rather than inventing a parallel one:

{
  "permissions": {
    "defaultMode": "auto",
    "auto": {
      "context": [
        "Trusted monorepo: github.com/acme/platform",
        "Package manager is pnpm; tests are vitest",
        "Staging DB at localhost:5433 is disposable"
      ],
      "allow": [
        "Test, lint, typecheck and build commands are always fine",
        "Reading and writing anywhere under packages/*/src is expected"
      ],
      "soft_deny": [
        "Never touch anything under infra/",
        "Confirm before any git push or tag"
      ]
    }
  }
}

Natural-language entries rather than patterns, because if you could express it as a pattern you'd have written an allow rule and never reached the classifier. soft_deny → forced prompt, not a hard deny, so it stays distinguishable from the real deny list.

Entry points

• cmd --permission-mode auto
• shift+tab cycle placement: after plan, and only once the user has opted in — the same treatment bypass gets, for the same reason.
• Not /mode:auto. Slash commands are agent-invokable; the existing reasoning for keeping bypass out of /mode applies just as hard here, arguably harder, since a model that can put itself into a mode where a model approves its own tool calls is a closed loop.
• permissions.disableAuto: "disable", enforced at every layer, mirroring disableBypass. Orgs need to be able to turn this off from user-global or managed settings and have it stay off.

Acceptance criteria

• deny and ask rules resolve before the classifier is consulted, in all cases, with tests pinning it.
• The root/home circuit breaker fires under auto exactly as under bypass.
• Sensitive writes (.env, .git/**, .ssh/**, persistence vectors) are not classifier-approvable without a content-specific allow rule.
• plan mode's write gate is unaffected — auto cannot be combined with or escape plan.
• Sub-agents inherit the mode, and anything that fails closed for sub-agents today still fails closed.
• Classifier decisions are logged with a reason, visible in-session and after the fact. "Why did it run that?" needs an answer.
• A classifier failure or timeout falls back to ASK, never to ALLOW.
• disableAuto is honored by the engine, the CLI, the TUI cycle, and any stored decisions.

Open questions / concerns

1. Latency and cost. Every unresolved call becomes a model call. Does the classifier run on a small fast model? Is it billed against the user's plan? A per-call round-trip on a build loop could be worse than the prompts it replaces. Some form of decision caching for identical (command, cwd, mode) tuples within a session seems necessary, though caching approvals is its own risk.
2. Measured false-negative rate. This is the number that decides whether the feature is usable, and it should ship in the docs, not be discovered by users. What fraction of genuinely destructive calls does the classifier approve? If it's not published, nobody can calibrate how much to trust it.
3. Prompt injection. A classifier in front of every tool call is a real defense-in-depth win — an injected instruction still has to get a tool call past the gate. But the classifier itself reads attacker-influenced content (file contents, web fetches, MCP responses). What isolates its input from the main context?
4. Interaction with dont-ask. Presumably mutually exclusive, since one converts would-be asks to denies and the other to model judgments. Worth stating explicitly.
5. Checkpoints. Command Code already checkpoints before every file modification, which makes an auto run rewindable in a way that matters a lot here. Shell side effects aren't covered by that, and shell is exactly where the classifier earns its keep. Anything to be done there?
6. Does taste learning feed this? Accept/reject signals are already being collected. A per-user model of which commands this developer routinely approves seems like the obvious differentiator versus a generic safety classifier — and closer to the product's actual thesis than a bolt-on gate would be.

Prior art

Claude Code shipped a classifier-backed auto mode as a research preview in March 2026 and is making it the default permission mode for new sessions on several plans as of August 2026. Their config shape is an autoMode block with environment / allow / soft_deny arrays, deny and explicit-ask rules evaluated before the classifier — which is the same layering proposed above. Docs: https://code.claude.com/docs/en/auto-mode-config

Worth diverging where it makes sense rather than cloning it; the taste angle in question 6 is the obvious place.

Use Case

• Rules can't cover what you didn't predict. Allow lists decay with every new script, repo, or toolchain. The classifier's value is the unpredicted tail — exactly where the friction is.
• Prompt fatigue is a security failure. When most approvals are npm test, people stop reading them. Cutting the boring 95% makes the remaining prompts legible again.
• It's safer than the escape hatch people currently take. Users who find auto-accept too narrow reach for --yolo, which skips the sensitive-write gate entirely. A middle rung reduces bypass usage.
• It unblocks features they already ship. Background tasks and worktrees only pay off unattended; an agent stalled on a prompt nobody's watching does nothing.
• The architecture already exists. Sub-agents auto-allow where the main loop prompts, with hard guards failing closed — the main loop just can't do it.
• Defense in depth against injection. Gating the proposed call catches actions a compromised context talked the model into, however it was persuaded.

Additional Context

No response

How important is this to you?

No response