Permissions & Safety

Permissions are usually the first safety decision when setting up an AI coding agent. ACT gives agents workflows that read, edit, search, and verify your project, so your client needs a permission strategy that fits how much autonomy you want to allow. For exact client settings, use the platform pages linked below.

What will the agent ask to do?

ACT workflows commonly lead the agent to request these tool actions:

Tool	Why the agent uses it during ACT workflows
`Bash`	Runs Git, Flutter/Dart tooling, tests, builds, installs, and project scaffolding
`Read`	Reads Specs, Work Items, docs, source files, and dependency code
`Write` / `Edit`	Creates or modifies Specs, Work Items, docs, and implementation files
`Glob` / `Grep`	Searches the codebase for existing patterns, APIs, and conventions

Supported clients gate these tools differently. After choosing a strategy, use your client’s platform page for exact setup instructions: Antigravity, Claude Code, Codex, Cursor, GitHub Copilot CLI, or OpenCode.

Which strategy should I choose?

AI coding agents run shell commands, read and write files, and search your codebase on your behalf. That’s what makes them useful, but it also means you need to choose how much autonomy to grant and where the safety boundary should sit.

The key tradeoffs are:

Safety vs friction: tighter permissions mean more approvals. Looser permissions mean fewer interruptions but more trust in the agent.
Local access: iOS Simulator, Android emulators, and physical devices work best when the agent runs natively on your machine.
Prompt injection risk: when an agent reads untrusted input or browses the web, malicious content could try to hijack the session. Isolation limits the blast radius.
Background autonomy: remote machines are useful when you want agents to run long implementation and verification loops without keeping your main workstation involved.

Strategy	Client support	Safety	Setup effort	Local devices & simulators	Friction
Permission rules	All supported clients	High	Low	Full access	Some prompts initially
DSP / yolo + non-sudo account	All supported clients	Medium	Medium	Full access	None
VPS / remote dev machine	CLI-first clients; editors via remote SSH support	High for your local workstation	Medium/High	Limited / remote-only	Low
Docker container	Best documented for Claude Code, Codex, and OpenCode	Highest when configured carefully	High	Limited	None

Strategy 1: Permission rules

Permission rules are the conservative default. You configure your AI client to allow common tool usage while keeping a permission boundary for unexpected actions.

This reduces repeated approval prompts without granting blanket access. It is the best starting point for most users because it works with every supported client and keeps full access to local simulators, emulators, and physical devices.

Some clients use permission files. Others use rules files, allowlists, sandbox settings, or app UI settings. Exact config locations and precedence are platform-specific, so keep this page as the strategy guide and use the platform pages for setup.

Advantages:

Easy to start with
Full access to local development tools and devices
Granular control over common commands and tools
Safer than disabling approval prompts entirely

Disadvantages:

You may still get prompts for commands outside your rules
Permission rules need maintenance as your workflow changes
Allowlists and rule files are convenience controls, not complete security boundaries

Strategy 2: DSP / yolo + non-sudo account

DSP / yolo mode skips normal approval prompts so the agent can run autonomously. Use it only inside a boundary you trust.

The usual local boundary is a dedicated non-sudo user account with no access to personal files, broad SSH keys, production credentials, or unrelated project secrets. This keeps local simulators, emulators, and device workflows available while limiting what the agent can affect.

Antigravity, Claude Code, Codex, and OpenCode expose DSP / yolo-style modes. Cursor’s closest equivalent is Run Everything, which skips Cursor’s safety checks. Treat it with the same isolation principle even though Cursor does not call it DSP/yolo.

Advantages:

No permission friction
Full access to native local tooling
Good fit for AI-assisted development and manual testing side by side

Disadvantages:

Requires a separate non-sudo account to reduce risk
Prompt injection risk is higher because approvals are bypassed
Anything accessible to that user account should be treated as accessible to the agent

Strategy 3: VPS / remote dev machine

A VPS or remote dev machine gives the agent a separate host to work on. This can be a fixed-price VPS, cloud workstation, GitHub Codespaces, or another remote development environment.

You can use normal permission rules on the remote machine, or run DSP / yolo mode there if you want fewer prompts. Either way, the main benefit is that mistakes affect the remote environment instead of your main workstation.

Remote machines are especially useful for long-running agent loops: repeated implementation, verification, and fix cycles that can stay online in the background. They work well for refactors, dependency upgrades, documentation work, backend/API tasks, CLI work, and test-fix loops that do not need direct device access.

They are not ideal for direct iOS Simulator or local physical-device testing. Android emulator support depends on the remote environment.

Advantages:

Keeps agent work away from your main workstation
Excellent for long-running agent loops
Can combine permission rules or DSP / yolo mode with a remote host boundary
Fixed-price VPS options can have predictable monthly cost

Disadvantages:

Requires remote environment setup and maintenance
Poor fit for local simulator and physical-device workflows
Cloud workstations and Codespaces may be usage-billed

Useful resources

Here’s a good guide for setting up and securing a VPS:

Self Host 101 - Set up and Secure Your Own Server

Once the VPS is running, you can use Tmux to keep tabs on your remote agents:

Build Anything with Tmux, Here’s How

Strategy 4: Docker container

A Docker container or devcontainer gives the strongest practical isolation for local development when configured carefully. It is especially useful when you want a reproducible environment or want to run DSP / yolo mode inside a disposable boundary.

Docker is not magic security. Bind mounts, Docker socket access, privileged containers, and mounted secrets can weaken the boundary. Keep the container narrow and avoid mounting more of your host than the workflow needs.

You can also combine strategies by running a container or devcontainer on a VPS or remote dev machine.

Advantages:

Strong practical isolation from your host machine
Safe place to use DSP / yolo mode when the container boundary is tight
Reproducible and shareable environment
Good fit for backend, CLI, test, and non-visual workflows

Disadvantages:

iOS Simulator is not available inside a container
Android Emulator requires additional setup for hardware acceleration passthrough
Visual testing is harder than with local native development
Higher setup effort than permission rules

Useful resources

Windows and WSL

On Windows, keep ACT, your AI client, and permission config in the same environment. If you use WSL, install and run ACT from WSL consistently. See Platform Support.

Troubleshooting

Repeated permission prompts

Repeated prompts usually mean one of these is true:

Approvals were accepted for the current session but not persisted to config.
Config was saved in the wrong scope, such as user-level instead of project-level, or vice versa.
The client needs to be restarted or reloaded after config changes.
Sandbox, Run Mode, or auto-run settings conflict with the allowlist or rules.
The command being run is outside the allowed pattern.

Use your platform page for the exact files, settings, and troubleshooting steps for your client.

Platform setup

This page helps you choose a strategy. For exact client settings and commands, see: