Approvals and safety

Before each tool call runs, Mework decides whether it runs straight away or asks you first. The security level draws that line and approval cards are how you answer; Plan mode and the sandbox add limits of their own.

Security levels

The security level is the button in the composer footer that shows the current level: Manual, Accept edits or Full access. A change applies at once, including to a running turn, its subagents and background work. Presets save the level (the built-in mework preset uses Manual), and branches and forks copy it.

Trusted folders are the conversation's workspaces — the project's folders and any you attach (see Workspaces and machines) — plus Mework's app-data folder, ~/Library/Application Support/com.mework.app on macOS and %APPDATA%\com.mework.app on Windows. A file the conversation's instruction files import with @ is treated as a file inside them, wherever it is: the file itself, not the folder it is in. To let the model work in another folder on the same terms as the project, attach it as a workspace rather than raising the level.

Call	Manual	Accept edits	Full access
`read`, `ls`, `find`, `grep` inside trusted folders	Runs	Runs	Runs
… outside trusted folders	Asks	Runs	Runs
`write`, `edit` inside trusted folders	Asks	Runs ¹	Runs
… outside trusted folders	Asks	Asks	Runs
`agent_spawn`	Asks	Runs	Runs
Shell commands, foreground or background; `web_search` and `web_fetch`; `workflow`; MCP tools; `lsp` in a workspace with its own `.mework/lsp.json` ²; the preview tools that start or stop a server, act on the page, or read its console, network or screenshots	Asks	Asks	Runs
The other preview tools; memory reads and project memory writes; `plan`, the handoff tools, `ask_user`, `task_wait`, `task_list`, `skill`, `tool_search`	Runs	Runs	Runs
Global memory writes	Asks	Asks	Asks

¹ Except Mework's own state file, document.v1.json in the app-data folder, which asks. ² In other workspaces, lsp follows the read rows.

Asked at every level

These ask even at Full access. Always allow never covers them, and a hook cannot approve them in advance:

A recursive delete (rm -rf, Remove-Item -Recurse and the like) aimed at the filesystem root, your home folder or a system folder such as /etc, /usr, /bin or /var (on Windows a drive root, your user profile, \Windows or \Program Files), or at a target built from a variable or command substitution. Other recursive deletes, such as rm -rf /tmp/build, follow the table.
Writes to global memory.
MCP tools whose server marks them as needing your interaction, or that you list in disabledAutoApproveTools — see MCP servers.
Taking over a preview tab you signed in to.
fork: the model's request to fork the conversation shows its own card and does not block the turn.

A hook can also force a card at any level, or skip one that is not in this list.

Approval cards

A card appears above the composer, or in the panel of the subagent that asks. It names the tool in the app's language, gives a risk level and the reason it asks, and shows what the call will do after any hook rewrote it: for every shell, the full command, marked [Background] when it will run in the background; for a file tool, the path; for web_fetch, the list of URLs; for a workflow, the run name.

Answer with Deny, Always allow (when offered) or Allow. Always allow stops asking for this tool in this conversation, its subagents and workflow steps included, up to the risk of the card you answered: a higher-risk call of the same tool asks again. Mework saves the answer with the conversation, so it still applies after Mework quits or restarts; it ends when you delete the conversation. Branches, forks and presets do not copy it. It is never offered for shell commands, MCP tools, preview tools that act on a page, or anything asked at every level.

A card left for 30 minutes is denied, and the model is told it timed out, not that you refused. Stopping the run withdraws its cards.

With hooks selected, each turn at Manual and Accept edits starts with a dialog listing the hooks and their commands: allow the turn, or cancel to end it.

Plan mode

In Plan mode the model writes a plan and asks you to approve it before it changes your files. Turn it on with the Plan switch beside the security level, mid-turn if you like. It is not saved in presets, so new conversations start with it off; branches and forks copy it.

Turning it on adds plan-mode instructions to the conversation and, the first time, the plan and exit_plan_mode tools. On a model that cannot take tools mid-conversation, the switch is gray if those tools were never sent in the conversation.

What it blocks. write and edit refuse any file Git tracks and any new file in a Git work tree that Git does not ignore, before any hook or card, on local, WSL and SSH workspaces alike.

What it does not block. Shell commands; files Git ignores or outside any repository; subagents and workflow steps, which get neither the tools nor the instructions; calls you run again by hand from the timeline. The security level still governs all of these.

Approving. The model writes the plan with plan, saved with the conversation rather than as a file, then calls exit_plan_mode, the only step that asks. The plan pane opens with a card: Send feedback sends what you typed, and the model revises the plan and asks again; Approve turns Plan mode off, and the model carries out the plan in the same turn. The card asks at every level, never offers Always allow, and times out after 30 minutes.

The sandbox

The sandbox runs the model's shell commands, foreground and background, inside an operating-system sandbox, and holds its file tools to the same limits. It is off by default and set per workspace.

Note The sandbox comes before the security level. No level, answer or hook widens what it lets a command or a file tool do, and a call it would refuse is refused before any card asks about it. Inside the sandbox the level still decides: below Full access, shell commands still ask. The sandbox does not cover preview servers, language servers, MCP servers, hooks or terminals you open.

Turn it on:

Click the workspace chip in the composer.
Click the gear beside the folder, or for an attached workspace the gear on its chip.
On Environment → Sandbox, turn on Run commands in the sandbox.

The setting applies to every conversation working in that folder, worktrees of it included. The line under the switch says whether the machine can sandbox; where it cannot, commands are refused before anything asks about them, never run outside the sandbox, and so are file tools on a WSL or SSH machine.

Machine	Sandbox	Setup
macOS	Seatbelt	None
Linux, WSL 2	bubblewrap	Install the system's `bubblewrap` package
Windows	Windows sandbox	Once, as administrator: Set up under Set up the Windows sandbox. It creates a hidden local account, `srt-sandbox`, and firewall rules, or reuses Claude Code's
Windows over SSH	Windows sandbox	An administrator runs, on that machine, the command the status line names

A sandboxed command can write only to the workspace, its own temporary folder and package caches, and the conversation's other workspaces on that machine with identical sandbox settings — not a file your instructions import from elsewhere; .git/hooks, .git/config, .mework, .vscode, .envrc and similar files stay read-only. On Linux and WSL, a workspace on a file system that ignores case — Windows drives in WSL, for one — protects those files less well: the sandbox can only protect a file by its exact name, so files such as .envrc, .mcp.json and .git/config may still be changed there, while the protected directories and every other limit hold. The sandbox can still be turned on; the workspace's sandbox settings point this out, and a workspace on a Linux file system, such as your home directory in WSL, is fully protected. It cannot read credentials such as SSH keys, cloud tokens, keychains and browser profiles, or see processes outside the sandbox, and environment variables named like secrets are removed. It reaches the network only through a proxy that applies the rules below.

The file tools — ls, grep, find, read, write and edit — read and write what a sandboxed command in the same workspace can, and nothing else: a write to .mework or outside the workspace, or a read of ~/.ssh, is refused, and a link in the workspace does not lead around it. On a WSL or SSH machine they run inside the sandbox; on this computer Mework checks each path against the same rules.

Network. Rules go by host name: allowing github.com allows whatever can be done through it.

Mode	Effect
Allowlist only (default)	Only hosts on the Allowlist. The default list covers GitHub, GitLab, Bitbucket and the main package registries; Restore the default allowlist puts it back
Any public host	Any public host
No network	Nothing

Allowlist entries go one per line: example.com, or *.example.com for subdomains only, each optionally with :port. Loopback and private addresses are reached only when listed. On macOS and Windows that includes the sandbox's own dev servers, so list localhost or localhost:port; on Linux and WSL the sandbox has its own loopback.

github.com
*.npmjs.org
localhost:5432

The Blocklist is never allowed, in any mode, and is checked before the allowlist. Further writable directories and Further unreadable paths take absolute or ~ paths on the workspace's machine.