Commands that reach outside
Most of what the agent does can be undone on your machine: a file edit has a checkpoint, a local commit can be reset. Some commands change things that live somewhere else (a shared git remote, a cluster, a cloud account, a production site, a database server) and no local undo brings them back. Syntic Code treats these as their own class and never runs them unattended in auto mode.
What is in the class
| Kind | Caught | Not caught (read-only or local) |
|---|---|---|
| Git remote | git push of any kind, flagged further when it forces (--force, -f, --force-with-lease, a + refspec), deletes a remote branch (--delete, :branch), mirrors, or targets main/master | git push --dry-run, git push -n, git fetch, git pull |
| Clusters | Changing kubectl/oc commands (apply, delete, scale, rollout restart, patch, …) and helm install/upgrade/uninstall/rollback on a cluster that is not a local one | kubectl get, describe, --dry-run; local contexts such as kind-*, k3d-*, minikube, docker-desktop, rancher-desktop, colima, orbstack |
| Infrastructure as code | terraform/tofu/terragrunt apply or destroy, pulumi up or destroy | terraform plan, pulumi preview |
| Cloud accounts | Changing calls made with cloud providers’ command-line tools (create, delete, update, deploy, terminate, remove storage, …) | Listing and describing |
| Production deploys | vercel --prod, vercel deploy --prod, netlify deploy --prod | Preview deploys |
| Remote databases | psql, mysql, mongosh, redis-cli and similar clients pointed at a host that is not this machine (by flag, connection URL or PGHOST-style variable); supabase db push, --linked, or a remote --db-url | The same clients against localhost |
| The host machine through a container | docker/podman run with --privileged, --cap-add=ALL or SYS_ADMIN, host PID or user namespaces, or a mount of /, your home folder or the engine socket | Ordinary containers |
| Files outside the project | rm of paths outside your working folders | Deletes inside the project |
Commands are read the way the shell would run them, so a command wrapped in sh -c '…', an alias or a chain (a && b) is still caught.
What happens, by mode
| Mode | A command in this class |
|---|---|
| auto | Always stops and asks. No allow rule, autoMode.allow entry or model review lets it through. |
| default, auto-edit | Asks like any shell command, unless an allow rule you wrote covers it. |
| plan | Refused. |
| don’t-ask | Runs only if an allow rule covers it; otherwise refused. |
| bypass | Runs. Bypass turns the checks off; add a deny or ask rule if you want a stop that holds in every mode. |
-p and background runs | Refused whenever it would ask, and the agent is told why. |
The prompt names the target
When one of these asks, the approval question says what it would act on, in every mode. For git push --force origin main:
Target: remote origin, branch main (force; main branch).Other examples of the Target: line: the kubectl context and namespace, the Helm release, the Terraform workspace or folder, the Pulumi stack, the cloud profile, region, project or subscription, the database host, and the paths an rm would delete. Read it before you say yes: it is the part that tells you whether this is your test cluster or production.
Make it stricter
To stop one of these everywhere, bypass included, write a rule:
{
"permissions": {
"deny": ["Bash(git push --force:*)", "Bash(terraform destroy:*)"],
"ask": ["Bash(git push:*)", "Bash(kubectl:*)"]
}
}See Rules for the pattern syntax.
The shell risk rating puts these commands at high risk. The few commands rated critical (and the catastrophic ones that are refused outright) are listed under Checks that always ask.