Plan Mode and Permission Prompts

Plan mode and permission prompts answer different questions. The mode determines whether Klaus is discussing a proposal or implementing it; permission checks determine whether an individual tool call may run. Accepting a plan does not bypass permissions, and changing permissions does not accept a plan for you.

• Plan before implementation: enter Plan mode explicitly with "Plan" in the composer's + menu (or /plan in the quick commands submenu). Klaus investigates, asks questions when needed, and presents a complete proposal you can expand, copy, download, and edit. "Yes, implement this plan" starts implementation; the feedback field requests a revision. Complex work in ordinary conversation may have a progress checklist; the conversation's mode determines whether it is planning. See Plan mode.
• Three permission presets: the composer dropdown offers "Ask for approval", "Approve for me", and "Full access". "Approve for me" sends eligible approval requests to an independent reviewer while retaining the current sandbox boundary. "Full access" disables ordinary sandbox isolation and approval prompts. Each conversation keeps its own selection. Changing it also sets the default for new conversations, while other existing conversations retain theirs. In an ordinary running conversation, a permission change takes effect at the next tool call. Plan mode preserves this selection, and execution uses it after planning ends.
• Permission cards: file writes, commands, and other tools that need confirmation show Deny / Allow. "Allow for this session" appears only when the engine can derive a safe rule from the current call. A suggested "Always allow…" rule is saved only after you select and approve it; the client does not invent allowance rules.
• Pre-authorization rules: configure allow, ask, or deny rules in Settings → Pre-authorization rules. Deny rules take precedence. Explicit ask rules can still require confirmation, including with "Full access" selected.
• Configuration settings page: "Settings → Configuration" sets defaults for new chats: approval policy (On request / Never ask), sandbox (Read only / Workspace write / Full access), network access, web search (Disabled / Cached / Indexed / Live), output verbosity and reasoning summary, at "Global configuration" or "Project configuration" scope. Changes are written to config.toml, which you can also open from the page.
• Visible approval review: with automatic approval enabled, chat shows each request's review state (reviewing / approved / denied / timed out) and the denial reason; recently denied actions can be approved once and retried from the /autoreview menu.
• Sandbox and scope: Settings → Configuration contains the approval policy and Read only, Workspace write, and Full access sandbox modes. Workspace write has an independent command-network setting; web search is controlled separately on the same page. Selecting Full access in the composer requires a second confirmation. The approved resource scope of a friend task remains in force.

See How permissions are resolved for the decision order and read-only behavior.