Permission Is Not a Sandbox
Codewhale has two visible dials that are easy to confuse. One describes the kind of interaction underway—Plan, Work, or Operate. The other describes how approval questions are handled—Ask, Auto-Review, or Full Access. This chapter separates those controls and follows a proposed tool call through policy, repository law, human approval, and actual command containment. The practical goal is to tell whether an action was merely permitted, or whether the platform also supplied the isolation a person may have assumed.
A useful diagnosis starts with the symptom. If a command did not run, the cause could be Plan mode, a typed denial, a repository invariant, a missing approval, an unavailable worker authority, or a sandbox refusal. If it did run, that proves only that the relevant gates allowed execution; it does not prove that the command was isolated from the operating system or that the resulting code is correct.
Two dials, not one
Plan, Work, and Operate describe the interaction mode. Plan is design-first: Codewhale can inspect and research, but the Runtime refuses file mutation and shell execution. Work is ordinary multi-step execution. Operate keeps the action-capable surface of Work but emphasizes goals, background workers, and verification for tasks that continue across independent streams.
Ask, Auto-Review, and Full Access describe permission posture inside an action-capable mode. Ask can interrupt for a decision. Auto-Review avoids opening ordinary user questions and resolves eligible calls through deterministic policy, with a narrow model-guardian path for some unresolved holds. Full Access removes ordinary approval prompts. None of these postures turns Plan into a write mode, changes a read-only child into a writer, or creates a sandbox that the operating system does not provide.
The distinction matters in both directions. Operate is not a secret fourth authority level; it changes scheduling emphasis while retaining the active approval, shell, repository, and sandbox boundaries. Full Access is not a statement that every action will run; explicit denials, catastrophic background or headless holds, and repository-law blocks remain meaningful. A person who sees “Full Access” should read it as “ordinary prompts are suppressed,” not “all later boundaries have been disabled.”
This gives Codewhale a more useful question than “is the agent trusted?” Ask instead: which mode admitted the tool, which posture handled approval, which policy layers applied, and what execution boundary was actually selected? Those questions describe a call precisely enough to investigate a surprising result.
From a proposed call to a running process
A model-requested tool call passes through an ordered pipeline. Effective configuration and runtime overrides are resolved first. Mode and tool admission can reject a call before policy rules are considered. Hooks may deny, ask, allow, rewrite the input, or add bounded context. The registered tool establishes its ordinary approval requirement. Typed permission rules can deny, ask, or clear ordinary approval, but they cannot erase a hook hold or a non-bypassable registered requirement.
Auto-review policy and the built-in safety floor can tighten the result. Repository law can add another hold. A remaining prompt is sent to the person when the current posture permits one.