Permissions and access
You choose how much W1 can do without asking. Under every setting there is a floor that never moves.
There are two separate questions here, and mixing them up is the usual source of confusion:
- Access mode — how much W1 may do before it has to stop and ask you. You set it.
- The floor — what W1 may never do, in any mode. You do not set it, and neither does W1.
Access modes#
| Mode | What it means |
|---|---|
| Approval required | Every action that changes something stops and asks. The most conservative way to work, and the right one in a repository you do not own. |
| Auto-accept edits | File changes inside the project go ahead without a prompt. Commands, network actions and anything outward-facing still ask. |
| Full access | W1 proceeds without approval prompts. The floor below still applies. |
Reads are never gated. Looking at a file, searching, or loading a skill does not ask permission in any mode, because those cannot change anything.
Full access is exactly what it says.
It is genuinely useful on a scratch project, a throwaway branch or a machine you can rebuild. It is a poor default on anything you would be upset to lose. In the CLI the same thing is --full-access, with --yolo as its memorable alias, and it applies to that one invocation only.
What an approval card tells you#
When W1 needs your say-so, it shows the actual thing it wants to do, not a category:
- the tool and the exact arguments — the whole command, the real path, the real URL
- the working directory it would run in
- the classified effects: reading, changing a file, deleting something, installing a package, making a network request, touching credentials, publishing or deploying, communicating outward, escalating privilege
- for network actions, the destination
You can approve it once, decline it, or allow it for the session.
What "allow for the session" actually grants#
Grants are by class, never by exact arguments — approving one click on a site would be useless if the next click on the same site asked again:
| Grant | Covers |
|---|---|
browser-write:<origin> | Every write action on that one site. |
risk:<reason> | Every command the floor flags for that same reason. |
tool:<tool> | Every call of that one tool. |
Grants last for the session. An unrecognised grant never matches, so the only failure mode is asking you again — never widening silently.
Declining is a normal outcome, not an error. If a run cannot proceed without something you refused, it ends in permission_denied and says so, rather than looking for a way around you.
The floor#
Some commands are never run, in any access mode, and never even reach an approval prompt. There is no setting that turns this off:
sudoand anything else that escalates privilege- piping the network into a shell —
curl … | sh - system-destructive commands:
mkfs,shred,dd if=,shutdown,reboot,halt pkill/killall, which can take out processes that have nothing to do with your project- git operations that destroy work you cannot get back: force-push,
git clean -fd, forced branch deletion,git checkout ., dropping or clearing stashes - recursive deletion, except for regenerable build directories inside the workspace —
node_modules,.venv,__pycache__, build output — so a cold rebuild still works - global
pip install. Python dependencies are installed into a virtual environment inside the workspace, so W1 cannot corrupt your system interpreter
Alongside that, every path W1 touches is confined to the project folder. A path that escapes it is refused by the runtime.
Gates are consent, not containment.
The floor and the approval card exist so nothing happens that you did not agree to. They are not a sandbox, and they are not a defence against a project that is itself hostile. Open folders you trust, the way you would with any tool that can run a build script.
Outward actions#
A few things are treated as outward-facing however permissive your mode is, because they leave your machine and cannot be taken back:
- publishing an artifact — W1 asks first, every time, and offers private or public
- writes on a website through the collaborative browser
- anything the effect classifier marks as deployment, publication or external communication
Where to set it#
Access mode is set per project in the desktop app and in VS Code, and shown in the run while it works. In the terminal it is a flag on the invocation — see the CLI reference.