Permissions
Open Settings → Permissions. Sandbox level has three levels:
| Level | Behavior |
|---|---|
| Strict | Asks before edits, commands, web access and anything else not proven read-only |
| Approve for me · Recommended (default) | Runs web searches, reads, edits and sandboxed commands inside the project; asks before files outside it, publishing, payments, unconfined code, private-network requests and sending to a provider this chat isn’t using |
| Allow all | Never asks for tool approval; your own deny and ask rules and consent to control other apps still apply. Choosing it needs a confirmation |
When a chat needs approval it shows Permission needed in the turn, with Always allow, Allow session, Allow once and Deny. The composer stays open: a message you send while a request waits declines it and steers the turn. Grants cover what the card says:
- Allow once covers the reviewed action.
- Allow session covers that tool in this chat, a browser’s routine actions or one desktop application. It is not offered for protected paths, explicit rules or paths outside your projects.
- Always allow stops asking for that tool in this project (clear it in
Settings → Permissions). One made inside the sandbox never covers a run
outside it, and outside the sandbox interpreters, write redirects and
commands that set variables such as
PATHstay exact-input. - A Quick Chat that reaches one of your configured projects asks (“Synoec is asking to read files in alpha.”). Allow session then covers reads in that project for this chat; the first edit asks again, and an edit grant includes reading.
- A Task’s requests appear in the parent chat; a background Task’s request outlives the turn and can still be answered.
A plain read runs without asking at every level: echo with literal words,
and git branch with only listing flags, git remote, git ls-files and
git describe. Each stage of a ; chain is classified on its own, as in a
&& chain, so pwd; ls runs unasked while pwd; rm file asks.
The CLI takes --permission-mode (auto, strict, acceptEdits, plan,
bypassPermissions, fullAccess, dontAsk). See the
permission policy.
A background job or interactive session holds the workspace to itself and
other work waits for it, unless the command is proven read-only, runs only on
another host over ssh, or declares a shared workspace. Jobs keep running
across model turns and client reconnects for as long as the engine lives;
restarting the engine ends them.
Each Bash call runs in a fresh shell with pipefail and closed stdin, so
dependent steps need && or an explicit set -e. Exit 141 is SIGPIPE: a
producer piped into a short reader such as head fails once the reader has
enough, while a draining reader such as sed -n '1,500p' lets it finish.