Approvals, the command sandbox & always-allow rules

    How Atlarix pauses for your approval before file edits and dangerous commands — while ordinary commands run inside a per-OS sandbox — and how always-allow rules work.

    How approvals work

    In Build and Debug modes, the agent's file edits wait for your approval: each shows up as a diff card inline in the chat, where you approve or reject it hunk by hunk. Ordinary shell commands are different — they run automatically inside a per-OS write-confining sandbox (writes stay in your workspace, network stays on), so the agent isn't blocked on routine work. Only commands flagged as genuinely dangerous pause to ask you first. Explore, Plan, and Review modes are read-only, so nothing can write in them at all. It's the same stance as Codex and Claude Code.

    Always-allow rules skip the pause

    When an edit or a dangerous command asks for approval, the card offers an “Always allow” option that saves a rule for this workspace. For files you can scope it to that exact file, its directory, or its extension; for a flagged command it's keyed to that specific dangerous pattern. Once a rule exists, matching actions run without pausing again — always-allow means “don't ask me again for this.” Ordinary (non-dangerous) commands never needed a rule; they already run in the sandbox.

    Want more actions to pause?

    If file edits apply without pausing, a broad always-allow rule probably matches them — for example an extension rule like “.py” auto-approves every Python file, or a directory rule auto-approves everything under a folder. Open Settings → the workspace's File permissions and remove the rule to bring the pause back. To make specific commands ask (or be denied) even though the sandbox would otherwise run them, add ask/deny rules in the workspace's Terminal permissions or commit them to .atlarix/permissions.json. Rules are per workspace, so changes never affect another project.