Permissions & safety

Nemocode runs commands and writes files on your machine. What it may do without asking is yours to set — and some things it refuses regardless. Several independent layers apply, from the mode you choose down to the operating system itself.

The five modes

/mode

Mode	What happens
Read only	It may read and search. No writes, no commands, and no plan to approve. The footer says read only on.
Plan	It may read and search and proposes a plan. Writing starts when you approve the plan. The footer says plan mode on.
Ask	Every file change and every command stops for approval. The footer says ask on.
Accept edits	It edits files freely, but every command stops for you. The usual choice; the footer says accept edits on.
Auto	It works without asking; only the confirm list (below) and your ask rules still stop it. Meant for runs nobody is watching. The footer says auto mode on.

Shift + Tab in the chat cycles through the same five, in that order. The mode is global, not per session. New installations start on Accept edits. In earlier versions the mode called Read Only was the plan mode; a saved Read Only becomes Plan on update, so nothing behaves differently.

When the agent's plan is approved, it continues in the mode you set under Settings ▸ General ▸ After a plan is approved — auto mode, or accept edits with shell commands still asking.

Rules: allow, ask, deny

/permissions

Beyond the mode you can write rules for single tools. Three lists, allow, ask and deny, checked on every tool call. When more than one matches, the stricter wins: deny > ask > allow > the mode. A broad allow can therefore never cancel a narrow deny.

Rule	Matches
`Bash`	Every shell command.
`Bash(npm *)`	Commands starting with `npm`.
`Bash(npm run test)`	Exactly this command.
`Read(**/.env)`	Reading or searching files matching the pattern.
`Edit(src/**)`	Changing files under `src`.
`WebFetch`, `WebSearch`	Fetching pages, searching the web.

In the permissions page: a adds (you choose the list), d removes (press it twice to confirm), Enter on the mode line steps to the next mode. Rules are set by you in this page — never by a command the agent runs.

Block list and confirm list

Two more lists work on shell commands only, as patterns (regular expressions), and have sensible built-in contents. You can add to them, remove from them, and press R to return one to the built-in version.

List	Effect	Built in, for example
Block list	Always refused, in every mode, even with every switch flipped. It does not ask.	Wiping a disk or formatting a filesystem, recursively deleting the root or your home folder, a fork bomb, shutting the machine down, changing permissions of the whole disk, removing core system packages.
Confirm list	Always asks, in every mode, and an entry on the allowed-commands list (below) does not silence it. Only Dangerously skip all permissions removes it.	Recursive delete or permission change that leaves the project, force-push, publishing to the npm registry, piping a download into a shell.

Saying yes once, for good

When a command stops for you, one of the answers is “allow this command from now on”. That is remembered per project. See or edit the list:

/allow            # show it
/allow npm test   # add one

The same list is under Settings ▸ Project ▸ Allowed commands. An entry covers that exact command and the same command with further arguments (bun test also allows bun test foo), but never a command that chains something on with &&, ;, a pipe or similar.

The project boundary

By default Nemocode works inside your project (plus the system paths a toolchain needs to read). If it needs something outside, it asks — the approval names the exact path. Answering never puts the path on the project's denied list (Settings ▸ Project ▸ Denied paths), where you can lift it again.

Per session you can widen or narrow this:

/paths                       # show what applies
/paths allow ../shared-library
/paths deny  ./infra/secrets
/paths clear                 # back to the project's own scopes

Denying always wins: it beats an allow, and it beats the global switch below.

Confine shell to project (Settings ▸ Advanced, on by default) applies the same boundary to shell commands: they may only touch your project and the system paths. Switch it off and commands are no longer restricted to the project by this check — the operating-system layer below still applies.

The two switches that remove limits

Both live under Settings ▸ Advanced, both need a confirmation to switch on, and both switch off immediately.

Switch	What it drops	What stays
Dangerously skip all permissions	Every approval — nothing asks any more: no rules, no confirm list, no mode.	The block list, and the project boundary.
Dangerously allow all paths	The project boundary for files and the shell.	Writing into the operating system is still refused. Reading there is fine. Denied paths and the protection below stay.

The operating system enforces it

Everything above is a decision Nemocode makes before a command runs. Because a clever command can hide what it does, the shell of the agent is additionally confined by the operating system, so a command that slips past every check is still stopped by the kernel:

System	Mechanism
Linux	Landlock. Needs kernel 5.13 or newer; without it Nemocode says so and falls back to the checks above.
macOS	Seatbelt (`sandbox-exec`).
Windows	A process of low integrity level: it can read, but write only into your project and a private temporary folder. Everything in your user profile and the system stays read-only for it.

The shell may write in your project and anywhere else that is not the operating system's own territory. It cannot write into system folders, and it cannot write into Nemocode's own protected data (next section). Temporary files and tool caches — for compilers, npm, uv, bun — are redirected to .nemocode/scratch/ in your project, so build tools work without opening anything up. That folder is the only part of .nemocode/ the agent may write to.

What the agent cannot touch

Your approvals only mean something if the agent cannot switch them off. So Nemocode's own settings, the project memory, hooks, MCP and plugin configuration live in a protected data folder that the agent's shell cannot write to — the operating system enforces that, not a rule the agent is asked to follow. The agent can also not talk to Nemocode's own server from its shell, and it can only run the tools it was actually given for the mission. Commands that name .nemocode/ (other than scratch) are turned away before they run.

Changing any of that is something you do, in the settings window or the panels — never something a command in the agent's shell can do.

Known limitation on Linux. The agent's shell cannot create, delete or rename entries directly in your home folder — for example the lock file git config --global writes. Existing files there stay writable. The same goes for the folders directly above Nemocode's protected data.

What Nemocode refuses, always

The block list from above is not a question but a refusal, in every mode and with every switch flipped. They do not ask, they do not run. If you know better for your machine you can edit the list — but that is a decision only you can make in the permissions page.

Getting back

Every file edit the agent makes can be undone: /undo reverts the last step, /redo brings it back; a new edit clears what could be redone. Both wait until no mission is running. Files that a step created are left in place rather than deleted — removing something you have since edited would be the worse mistake. What a shell command changed is not covered by undo.

For work you want kept apart from your main tree entirely, give the session its own git worktree — see Sessions & projects.