Configure auto mode

Auto mode lets the agent work through routine steps without asking at every turn, while still stopping for anything with real consequences. This page is for the people who decide how much freedom that is: team leads writing project rules, and administrators setting policy for everyone.

How auto mode feels day to day is covered in Permission modes. This page covers the parts you can configure: the reviewer, the rule lists, where each setting may come from, and how to switch auto mode off.

How a call is judged

In auto mode, each tool call passes through these stages in order. Any stage can stop it.

Permission rules. Deny rules, ask rules and plan mode behave exactly as in any other mode. Auto mode never overrides a deny.
Data-leaving check. A local check looks for commands that would send local data off the machine: uploading a file, copying to a remote host, piping into a network tool, or putting secret-looking values in a URL. These always reach a person, even when the reviewer is off or unreachable.
Auto mode rule lists. Your hard_deny, soft_deny and allow patterns, described below.
The model review. A small, fast model reads the call against a built-in safety policy plus your plain-language rules, and answers allow, ask, deny or block.
Built-in high-impact checks. A fixed list of actions (deleting outside the project, sudo, publishing a package, pushing to a remote, and more) always asks. No setting can turn these off. The list is in Permission rules.

Anything but “allow” becomes an ordinary approval prompt that carries the reason. In a non-interactive run (-p) there is nobody to ask, so a prompt becomes a refusal.

The model review

The review is on by default. The reviewer is the session’s helper model (smallModel), so it adds little time or cost per call.

What skips the review: read-only calls (file reads, searches), edits to files inside the project folder, and calls that one of your allow patterns names.

What is always reviewed while the review is on: WebFetch and WebSearch. They count as read-only, but what they send out sits in the URL or query, so they are reviewed anyway.

It fails closed. If the reviewer cannot be reached, takes longer than 20 seconds, or gives an answer that cannot be read, the call is put to the person (or refused in a non-interactive run). It is never allowed by default.

Reviewer switches

These live in the autoMode block:

Key	Default	Effect
`review`	`true`	`false` turns the model review off. Auto mode then judges shell commands with its fixed risk checks only.
`reviewReadOnly`	`false`	Also review read-only calls. Safer, but slows every step.
`classifyAllShell`	`false`	Send every shell command to the review, including read-only ones and ones an allow rule or an earlier “always allow” answer would have let through.

{
  "autoMode": {
    "review": true,
    "classifyAllShell": true
  }
}

The environment variable SYNTIC_AUTO_MODE_REVIEW overrides the review switch from any file: 0, false, no or off turn the review off, and any other value turns it on. Only those exact “off” spellings count, so a typo leaves the review on.

⚠️

Because the environment variable wins over settings, a policy file alone cannot stop a person from turning the review off for their own runs. If your rules require the review, check how your machines set the environment, or switch auto mode off altogether with disableAutoMode.

/status shows whether the review is on for the current session.

The rule lists

Three lists let you adjust the built-in policy. They add to it; they never replace it.

List	When an entry matches
`hard_deny`	The call is refused outright, even if a permission allow rule or an earlier “always allow” answer would have let it through.
`soft_deny`	The call becomes an approval prompt. (`deny` is accepted as an older name for this list.)
`allow`	The call skips the model review. It never overrides a permission deny rule or the built-in high-impact checks.

When entries in several lists match, hard denies win over soft denies, which win over allows.

{
  "autoMode": {
    "allow": [
      "Bash(cargo test*)",
      "Bash(pnpm lint:*)",
      "running the project's own scripts in ./scripts"
    ],
    "soft_deny": [
      "Bash(git push*)",
      "editing anything under .github/workflows"
    ],
    "hard_deny": [
      "Bash(rm -rf /*)",
      "WebFetch(domain:paste.example)",
      "uploading files to any external service"
    ]
  }
}

Two kinds of entry

Form	Example	How it is checked
Pattern `Tool(pattern)`	`Bash(git push*)`	Matched locally, before any model call. `` matches any run of characters; a trailing `:` matches the rest of a command.
Sentence	`editing CI configuration`	Given to the model review as an extra rule. Only takes effect while the review is on.

What a pattern is matched against depends on the tool:

Tool	Matched against
`Bash`	The full shell command
File tools (`Read`, `Edit`, `Write`, …)	The file path
`WebFetch`	The URL, or the host with `domain:`
Anything else	The raw tool input

A "$defaults" entry, which some shared configurations carry, is accepted and ignored. The built-in rules always apply.

Where each setting may come from

Auto mode reads the autoMode block from every settings file and combines them:

Part	User file	Project and local files	Managed policy
`soft_deny`, `hard_deny`	Yes	Yes	Yes
`allow`	Yes	No	Yes
`review`, `reviewReadOnly`, `classifyAllShell`	Yes	No	Yes

Lists from every allowed file are joined. For the switches, the strongest file wins, so a managed value overrides a user’s own.

The rule behind this table: a repository is untrusted input. A project’s own files may make auto mode stricter, but never looser. For the same reason, a project file cannot start a session in auto mode at all; permissionMode: "auto" in .syntic/settings.json is ignored.

Policy for everyone

A managed policy that keeps the review strict and blocks the riskiest things outright:

{
  "autoMode": {
    "classifyAllShell": true,
    "hard_deny": [
      "Bash(curl * | sh*)",
      "WebFetch(domain:pastebin.com)",
      "sending source code or credentials to any service outside example.com"
    ],
    "soft_deny": [
      "changing infrastructure, deployment or CI configuration"
    ]
  }
}

Tools for writing rules

Tool	What it does
`/auto-mode-setup [focus]`	Drafts rules that fit the current project, each with a reason, and saves them to your user settings only after you confirm. Interactive sessions only.
`/permissions auto <allow\|soft_deny\|hard_deny> <rule>`	Adds one rule to your user settings. Add `--project` to add a deny rule to the project file instead.
`syntic auto-mode reset`	Removes the `autoMode` block from your user settings so only the built-in rules (and any project or managed rules) apply. Asks first; `--yes` skips the question.

After a reset, the command names any other file that still has an autoMode block:

Auto mode is back to its built-in rules.
Still in effect: the autoMode block in /etc/syntic/settings.policy.json.

Switch auto mode off

{ "permissions": { "disableAutoMode": "disable" } }

The top-level spelling "disableAutoMode" and the value true work too. Any settings file may set it, a project’s included, because turning it off only tightens. Once one file sets it, no other file can turn auto mode back on.

With it set, every way into auto mode lands in the default mode instead:

--permission-mode auto or "defaultMode": "auto" starts in the default mode, with the note: “Auto mode is turned off by the disableAutoMode setting; using the default permission mode.”
Shift+Tab skips the auto step.
A host program asking to switch to auto gets the default mode.

When rules do not behave as expected

Symptom	Likely cause
An `allow` pattern in `.syntic/settings.json` has no effect	Project files cannot add `allow` entries. Put it in your user settings, or ask an admin to add it to policy.
A sentence rule is ignored	Sentences need the model review. Check `/status` and `SYNTIC_AUTO_MODE_REVIEW`.
A command still asks despite an `allow` pattern	It hit a permission ask rule, the data-leaving check, or a built-in high-impact check. Those always ask.
Every call asks for a while	The reviewer is unreachable or slow; the review fails closed. Try again shortly.
`-p` runs fail with refusals	Anything that would prompt is refused when nobody can answer. Add `allow` patterns for the routine steps, or narrow what the run does.
`Shift+Tab` never reaches auto	`disableAutoMode` is set in some file. `syntic doctor` and `/status` show which files are read.

Managed MCP servers Feature availability