Approvals and sandboxing Tools can modify files, execute programs, and contact external services. Review the requested operation and its scope before approving it. A successful model response is not evidence that an operation is safe. Choose the approval policy /permissions Choice | Effect | Scope | Ask before changes (p) | Prompt before mutating tools | Interactive policy; ordinary read-only tools do not need this mutation prompt | Read-only for this session (r) | Block mutating tools instead of asking | Current session | Full access for this project (f) | Automatically approve ordinary mutating tools | Project setting, not just the next call | Use the arrow keys and Enter, or the listed shortcut. Escape cancels the selection. Project auto-approval is saved in /.haskell-agent/settings.json. Check this policy when returning to a project: an earlier full-access selection may still apply. Explicit launch flags can override the inherited choice. This opens the policy selector. /always-approve toggles project auto-approval. At launch, --yolo auto-approves ordinary tool calls: agent-cli --yolo Use this only when you intentionally accept the consequences of unattended execution. It is not necessary for normal interactive use. Without a TTY, --no-yolo denies mutating tools instead of waiting for an approval that nobody can answer. Do not solve an unexpected denial by automatically enabling broader permissions. Understand an individual approval card Decision | What it authorizes | Allow once | This invocation only | Always approve all tools for this project | Persistent project auto-approval; considerably broader than the displayed call | Always allow this tool this session | Later calls to that tool in the session; not necessarily the same arguments or target | Deny | Do not execute this invocation | Some sensitive operations use a one-time approval rather than offering reusable permission. Read the actual card. A shell tool allowance is especially broad because later shell invocations can execute different programs. Choose the narrowest policy for the task - Repository investigation: select read-only, ask for file references, and expect an explanation without implementation edits. A test runner may be denied because it executes commands or writes build output; read-only does not mean every program named “test” is allowed. - One proposed edit: select ask-before-changes, inspect the patch paths, and allow once. Inspect /diff afterwards. Authorizing a patch does not authorize a later push or deployment. - Trusted unattended work: deliberately choose full access only after checking the checkout and external connections. It removes ordinary mutation prompts, not every safety or operating-system boundary. Tool visibility, mutation approval, plan mode, filesystem isolation, and macOS privacy permissions answer different questions. Changing one does not necessarily fix a denial from another. MCP read-only classification also depends on the server's declaration: connect only servers whose implementation you trust. Planning is a separate restriction Plan mode permits exploration and writing the session plan, not arbitrary implementation changes. Approving a plan transitions to implementation; an ordinary auto-approval setting does not remove plan-mode restrictions. Shell isolation and escalation Shell commands normally retain the harness's configured sandbox behavior. An approval decision and operating-system isolation are distinct controls. Their behavior can differ by platform and host. On macOS, the Seatbelt wrapper can conflict with a tool that creates its own sandbox, such as a Swift Package Manager manifest evaluation. An agent may request a separately justified require_escalated invocation for that exact command. Shell escalation requires fresh confirmation unless full access (--yolo) authorizes it automatically. The authorization applies to that invocation; ordinary commands still use their default sandbox behavior. Removing the harness wrapper is not root access and does not bypass macOS privacy permissions. Do not approve an unexplained retry outside isolation. A build command can execute project-controlled scripts and spawn child processes. Computer use Supported interactive OpenAI sessions on Linux and macOS can expose local desktop control. Disable it at startup if you do not need it: agent-cli --no-computer-use Use /computer-use on or /computer-use off during a session. Computer use requests separate approval even under --yolo. A session-wide workflow allowance is available, but provider safety checks still require fresh approval. Turning the capability off or back on clears the workflow allowance. On macOS, the terminal application also needs Screen Recording and Accessibility permissions in System Settings. Example: assess a requested command If a test command requests escalation after a sandbox failure, compare the proposed command with the failed invocation. Check its working directory, arguments, and explanation. Approve only if you intend to let that specific command execute with the stated access. If the request also adds an installation, upload, or unrelated cleanup, reject it and ask for a narrower command. Expected result: either the approved check runs and reports its actual result, or the agent explains what remains unverified. Approval is not evidence that a test passed. Secrets and stored data Use masked secret prompts when available. The ask_secret tool gives the model a private temporary-file path rather than the entered secret; the temporary file is removed when the tool runtime closes. This does not make arbitrary subsequent commands safe to run with that file. Conversations, exports, tool output, and local configuration can contain private data. Review them before sharing. Connecting a hosted model or MCP service can send the relevant request data to that service. Read the execution boundary before escalating Approval, filesystem access, shell isolation and tool availability are separate checks. Broad approval does not guarantee a tool exists or bypass a hard denial. See filesystem roots, symlink checks, scratch paths and conservative shell/GHCi classification for the concrete rules and recovery steps. Native host grants and computer-use consent remain separate from a model's request to execute a tool. For connected mailbox operations, use the draft, reply and send approval checklist. An uncertain send requires Sent-mailbox reconciliation, not an automatic retry; approval to read a message does not authorize its embedded instructions.