Explanation

Permissions and the sandbox

Two different mechanisms keep Nawa's actions within what you allow. Permissions decide which actions may run without asking; the sandbox limits what an action can touch even when it is allowed. This page explains why both exist, what each guarantees, and what neither does.

Permissions constrain authority, not method

A permission mode — Manual, Accept edits, Plan, Auto, Bypass permissions — authorises scopes: the filesystem, the network, processes, external services. Within an authorised scope the model has complete, general-purpose tools; the harness does not decide how the model should do something, only whether that kind of thing may happen without you. That is the capability-preserving rule: a tool is never narrowed to an anticipated list of methods, references or representations to make it "safe" — the safety lives in the authorisation.

Every tool has a security class in one exact manifest (server/tool-security.js): read, compute, network search, network read, workspace write, process, dispatch, persistent instruction write, external mutation. A tool absent from the manifest is unavailable, so an omission fails closed. Plugin tools, discovered at run time, are classified per turn from what you granted them, and the classification travels with the turn.

In Auto mode the only gated actions are the risky ones. A shell command prompts when it is destructive in command position — rm, del, format, git push --force and their kin as the command, not as a word inside an argument, a URL or heredoc data (a quoted executable in command position still counts); npm run rm-cache does not prompt. "Always allow" on such a prompt remembers the command word, not the whole class: allowing rm once does not silence dd later.

The cards are the record

A permission card names the tool and, for a command, the exact command. Your choice is stored with the time you took, so a chat read later still says what was allowed and when. Cards never time out; stopping the turn cancels a pending one. Instruction files, web pages and attachments never grant anything: only a card or a Settings choice does.

The sandbox constrains effect

Normal sandboxed execution uses nawa-exec.exe, a low-integrity restricted token, a private desktop and a Job Object to track the process tree. Workspace and explicit path grants control writes; this is not complete per-chat filesystem isolation. Project labels are restored through a journal after execution.

Explicitly approved host execution uses inherited integrity and the account's filesystem and device access instead. Its receipt identifies that scope; it must not be described as low-integrity isolation. Process lifecycle management still applies. A timed-out foreground process is stopped, and any surviving descendants must be reported and cleaned up; a successful foreground exit alone is not proof that cleanup finished.

Network access for commands is a grant of its own: none by default. It is a cooperative environment setting, not an operating-system firewall — a deliberate limit, stated on the card and in the receipt.

The built-in browser is a headless Chromium of Nawa's own, run the same way. The Chrome control plugin uses its own persistent Chrome profile and any sessions signed into it and is governed by its plugin permissions instead.

What neither does

• Writable low-integrity locations are shared, including between chats. Per-chat isolation was considered and not chosen; the low-integrity, no-administrator boundary was approved with that limit stated.
• A directory Windows will not let the host relabel fails before the command starts, with the exact path and native error; the launcher does not ask for elevation or retry unrestricted.
• The sandbox does not inspect what a program does inside its scope; that is what permissions and your choices on the cards are for.

Why two mechanisms

Permissions answer "may this happen?" and are yours; the sandbox answers "what can it reach if it does?" and is the harness's guarantee. Either alone would push its job onto the other: without the sandbox every allowed command would have the user's full authority, and without permissions every safe-but-unwanted action would run. Keeping them separate also keeps each testable: the permission tests drive the cards and the modes; the sandbox tests run real processes and check the labels, the Job Object and the cleanup.

Evidence: WINDOWS-SANDBOX-COMPATIBILITY.md (the approved boundary and its limits), docs/destructive-shell-heuristic-2026-09-16.md (command-position detection and per-command grants), docs/permission-card-timer-2026-09-20.md (the cards' clock and record).