Safety and the sandbox
What it can never do, what it asks about, and how much disk it reaches.
An agent that runs commands needs limits that do not depend on the model behaving. motita has two layers, and only one of them is yours.
The floor
Some commands are refused every time: disk formatting and partition tools, shred, dd to an output, power-state commands, and rm, mv, cp or ln aimed at /, your home, a system path, or the folder that contains your workspace (including after sudo, xargs or find -exec). No key, variable or flag relaxes the floor.
Allow, ask, deny
| Verdict | When |
|---|---|
| Allow | The command changes nothing, or only the workspace: make, go build, npm test, your own ./scripts/*. It runs silently, because a policy that asks about those gets switched off. |
| Ask | It reaches the network or the system, writes outside the workspace, or cannot be classified. You are asked before it runs. |
| Deny | Strict mode and the line cannot be placed. |
The sandbox
Commands run confined, with no Docker. Memory, CPU time, processes, open files and output size are limited, optionally with no network inside the command. On Linux with Landlock, a command cannot write outside the directories it works in and cannot read motita's logins, configuration or your git credential store.
Disk access
Settings → Security chooses how much of the disk the agent reaches:
- Workspace only (default): file edits outside the session's folder are refused, and on Linux a command cannot read or list your files elsewhere (home,
/home,/mnt, ...). - Whole disk: both reach anywhere your account can. The page asks first and spells out the risk. motita's own logins stay hidden either way.
Where nothing confines a command (Windows, macOS, Linux without Landlock), the agent asks before the project's own code runs, unless you turn that off.
Each session also gets its own HOME, and cannot read the other projects and sessions of the same gateway.