AI Agent Safety

AI agents are powerful tools that can read files, edit code, and run commands on your behalf. This makes it important to think about what an AI agent should and should not have access to, and to verify its work before accepting it into your codebase.

Use an Isolated Environment

The most effective safety measure is to run AI agents in an environment that does not contain anything the agent should not have access to. Consider:

Running your development environment in a virtual machine or container dedicated to AI-assisted work. This limits what the agent can see and do to the contents of that environment.
Using a separate user account for AI-assisted development, so the agent cannot access files, credentials, or configuration belonging to your primary account.
Keeping sensitive data such as production databases, customer data, and proprietary secrets outside the development environment where the agent runs.

Secure SSH Keys and Credentials

AI agents can run shell commands, which means they can potentially use any credentials available in the environment. To limit this:

Do not run an ssh-agent with broadly scoped keys loaded while working with an AI agent. If the agent can run ssh or git commands, it can reach any host those keys grant access to.
Use SSH keys with narrow access. For example, deploy keys configured for a single repository (VCS-only access, no shell) are safer than personal SSH keys that grant access to many systems. GitHub, GitLab, and similar services support repository-specific deploy keys for this purpose.
Store credentials (API keys, tokens, database passwords) in a secrets manager or environment that the AI agent cannot access, rather than in files or environment variables in the working directory.
Review your ~/.ssh/config, ~/.netrc, and similar files to ensure they do not provide the agent with unintended access to remote systems.

Configure Pre-Approval Settings

Wing's Project Properties let you control what the agent is pre-approved to do without asking for confirmation. Review these settings to ensure they are consistent with your requirements:

Preapprove Edits For -- By default, the agent may edit files in all project directories under version control. You can restrict this to specific directories or disable pre-approval entirely so that the agent must ask before every edit.
Preapprove Running Commands -- Disabled by default. When enabled, the agent may run shell commands without asking. Leave this disabled unless you are working in an isolated environment where unrestricted command execution is acceptable.
Preapprove Revision Control Commands -- Disabled by default. When enabled, the agent may run VCS commands without asking. Consider leaving this disabled so that operations like push require explicit approval.

While the Tasks Manager is on, its own Permissions settings are used instead. They offer the same choices, except that edits are either pre-approved in all project directories or not at all. These settings are described in detail in Configuration.

Know Each Agent's Safety Gaps

Wing can stop an agent from doing what your run mode and pre-approvals do not allow, but only when the agent gives it the chance. An agent run in its own terminal interface tells Wing before each action, and Wing can block it. An agent run over ACP, such as goose or Codex ACP, asks Wing before it acts, and Wing answers from your pre-approvals or asks you. When an agent does neither for some action, Wing cannot stop that action, and Wing warns you before a task starts in a run mode affected by it.

The table below lists, for each agent:

Safety -- Where the agent ignores Wing's safety constraints, which are your Plan or Ask For Approval run mode and pre-approvals, and what the agent does in Auto-Approve. Where Auto-Approve does no safety checks, use it only in an isolated environment, as described above.
Autonomous Task Manager -- How well the agent runs the Tasks Manager and its queues of tasks while you are not watching, from best to worst: "Works best", "Works well", "Works" (with the problems listed under Missing Support), "Limited" (for the reason given), and "Not ready". Unattended tasks need Auto-Approve in practice, so the column says where that means working without safety checks.
Missing Support -- What the agent does not do that Wing would need.

The agents are grouped by our assessment of safety and their suitability for use in autonomous development.

Agent	Safety	Autonomous Task Manager	Missing Support
Recommended - Safe to Use
Claude Code (and Claude Code ACP)	`Auto-Approve` checks each step for safety, and blocks risky ones or asks you about them.	Works best: the agent most used with Wing	--
Codex	`Auto-Approve` checks for safety each step that would leave Codex's sandbox, and blocks risky ones.	Works well	Runs commands in the project without asking, even in `Ask For Approval`
Functional - Some Safety Concerns
Antigravity	`Auto-Approve` does no safety checks.	Works well but without safety checks	--
Copilot	`Auto-Approve` does no safety checks.	Works well but without safety checks	--
Cursor	Partly ignores Wing's safety constraints. `Auto-Approve` does no safety checks.	Works well but without safety checks	Never asks before changing a file
Copilot ACP	`Auto-Approve` does no safety checks.	Works but without safety checks	Cannot be sent a message while it works
Not Recommended
Antigravity ACP	`Plan` mode tasks can change files. `Auto-Approve` does no safety checks.	Limited: a task can hang when its model is overloaded	No read-only `Plan` mode
goose (ACP only)	`Plan` mode tasks can change files. `Auto-Approve` does no safety checks.	Works but without safety checks	No read-only `Plan` mode
Cursor ACP	Partly ignores Wing's safety constraints. No `Auto-Approve`.	Limited: tasks stop for you to approve commands	Never asks before changing a file; no `Auto-Approve`
Codex ACP	Ignores Wing's safety constraints, even in `Plan` mode. `Auto-Approve` does no safety checks.	Works but without safety checks	Never asks before changing files or running commands in the project
OpenCode	Partly ignores Wing's safety constraints. `Auto-Approve` does no safety checks.	Works but without safety checks	Wing can stop only the actions it asks you about
OpenCode ACP	Your own OpenCode settings can override Wing's safety constraints. No `Auto-Approve`.	Limited: tasks stop for you to approve commands	No `Auto-Approve`

The ACP versions of agents, such as Codex ACP, are listed only when the Show ACP Versions of Agents preference is enabled; see Setting Up an AI Agent. Use the plain version of an agent wherever there is one. Where an agent has no Auto-Approve, an Auto-Approve task runs in Ask For Approval instead. See Using Wing with an AI Agent for what each run mode selects on each agent.

The sections below give the details for each agent, in the order of the table.

Claude Code

Claude Code and Claude Code ACP are recommended and safe to use.

Safety: Wing can stop anything Claude Code does that your run mode and pre-approvals do not allow, and its Plan mode cannot change files. In Auto-Approve, Claude Code checks each step for safety before doing it, and blocks risky ones or asks you about them. Auto-Approve needs a Claude Max, Team or Enterprise account.

Autonomous Task Manager: Claude Code is the agent most used with Wing, and the best for running the Tasks Manager. After an update, Claude Code sometimes shows a new prompt in its window. Wing answers the ones it knows about, and any other waits for you.

Codex

Codex is recommended and safe to use. Codex ACP is not recommended.

Safety: Wing can stop anything Codex does that your run mode and pre-approvals do not allow. Codex also runs commands in a sandbox of its own that keeps them from changing anything outside the project, and its Plan mode cannot change files. In Ask For Approval, Codex runs commands inside the project without asking, because its sandbox already limits them. In Auto-Approve, Codex checks for safety each step that would leave its sandbox, which would otherwise need your approval, and blocks risky ones. Steps inside the sandbox run without a check, as they do in Ask For Approval.

The first time Codex runs in a directory it asks whether to trust it. If you press Esc instead of answering, Codex runs without telling Wing what it does, so Wing cannot stop anything. Codex's sandbox does not work inside Docker.

Run as Codex ACP, Wing cannot stop Codex doing anything inside the project. Codex never asks before changing files or running commands there, even in its own mode named "read-only", so Ask For Approval is not available. Its Plan mode only tells it not to change files, and nothing prevents it. It does ask before touching files outside the project and before using the network.

Autonomous Task Manager: Codex runs the Tasks Manager well. When its model reaches a rate limit, Wing pauses the queue and shows the task it stopped as failed, to run again later. Codex ACP can run it only in Auto-Approve, which does no safety checks on anything inside the project, so use it only in an isolated environment.

Antigravity

Antigravity is functional, with some safety concerns. Antigravity ACP is not recommended.

Safety: Wing can stop anything Antigravity does that your run mode and pre-approvals do not allow. Run as Antigravity ACP, Antigravity asks Wing before it acts, but it has no read-only Plan mode. A Plan mode task runs in Ask For Approval instead, so it can change files without asking wherever your pre-approvals allow edits. Antigravity's Auto-Approve does no safety checks, because its only other setting still stops for every command.

Autonomous Task Manager: Antigravity runs the Tasks Manager well, but only in an Auto-Approve that does no safety checks. When its model is overloaded or reaches a rate limit, Wing pauses the queue and shows the task it stopped as failed, to run again later. Antigravity ACP is limited, because a task can hang when its model is overloaded.

Copilot

Copilot and Copilot ACP are functional, with some safety concerns.

Safety: Wing can stop anything Copilot does that your run mode and pre-approvals do not allow. Copilot's Auto-Approve does no safety checks, because it has no setting between asking about everything and allowing everything. The first time Copilot runs in a directory it asks whether to trust it. If you do not accept, it runs without telling Wing what it does and without Wing's tools, so Wing cannot stop anything.

Autonomous Task Manager: Copilot runs the Tasks Manager well, and Copilot ACP runs it, but both only in an Auto-Approve that does no safety checks. Copilot ACP cannot be sent a message while it is working, and reports a canceled task as finished. Wing does not use Copilot's autopilot mode, which answers a task's questions by itself instead of passing them to you.

Cursor

Cursor is functional, with some safety concerns. Cursor ACP is not recommended.

Safety: Wing can stop the commands and tools Cursor runs, but never sees its file changes, because Cursor does not ask before changing a file in any run mode except Plan. Your edit pre-approvals therefore have no effect on it. Run as Cursor ACP, it has been seen changing a file outside the project without asking. Cursor's Auto-Approve does no safety checks, and blocks only the commands that Cursor's own settings block. Cursor ACP has no Auto-Approve.

Autonomous Task Manager: Cursor runs the Tasks Manager well, but only in an Auto-Approve that does no safety checks. When Cursor cannot reach its service, Wing pauses the queue and shows the task it stopped as failed, to run again later. Cursor ACP is limited, because its tasks stop about twice each for you to approve a command, and canceling a Cursor ACP task does not stop a command that is already running.

The first time Cursor runs in a directory it asks whether to trust it. Cursor will not start if its settings file contains a setting it does not recognize.

goose

goose runs over ACP only, and is not recommended.

Safety: goose asks Wing before it acts, but it has no read-only Plan mode. A Plan mode task runs in Ask For Approval instead, so it can change files without asking wherever your pre-approvals allow edits. goose's Auto-Approve does no safety checks, because its only other setting still stops for every change and command.

Autonomous Task Manager: goose runs the Tasks Manager, but only in an Auto-Approve that does no safety checks, and its Plan mode tasks are not read-only.

OpenCode

OpenCode is not recommended, neither with its TUI nor via ACP.

Safety: OpenCode asks before it acts only because Wing passes it your pre-approvals when it starts, and any permissions set in your own OpenCode settings replace them. Wing can stop only the actions OpenCode asks you about. Anything else it does goes ahead, even where your run mode and pre-approvals do not allow it. OpenCode's Auto-Approve does no safety checks, and blocks only what OpenCode's own settings block. OpenCode ACP has no Auto-Approve.

Autonomous Task Manager: OpenCode runs the Tasks Manager, but only in an Auto-Approve that does no safety checks. OpenCode ACP is limited, because it has no Auto-Approve, so its tasks stop for you to approve commands.

Add Site-Specific Requirements

Wing comes with built-in instructions that increase AI safety — for example, the agent is instructed not to push to remote repositories or perform other destructive VCS operations without first asking for permission. These are written into the guides in the .wing directory, which every agent reads. You can add your own site-specific requirements on top of these:

Add rules to the AGENTS.md file in your project's top-level directory (or CLAUDE.md for Claude Code). The agent reads this file at the start of every session and follows the instructions it contains. For example, you might prohibit access to specific directories, require that certain tests pass before any commit, or restrict which external services may be contacted.
Most agents also read a file of their own outside the project, for instructions that should apply across all your work; each documents where that lives.
Ask the agent about the best options for your particular requirements — it can help you craft effective safety rules for your situation.

Trust Peer Machines

Peers, as described in Sending Tasks to Other Machines, ask the agents on other machines to run tasks by leaving messages in a mailroom they share. Keep the mailroom reachable only by your own machines, and use separate mailrooms for separate groups of machines. Peers with other repositories that use the mailroom with the same key can also send each other reports and handoffs. Wing limits what a request can do:

Each machine needs the Mailroom Key set in Peers.... Messages and the state each machine records in the mailroom are encrypted with it, and a machine declines every message not encrypted with it, so others who can reach the mailroom can't read or change its tasks or make it run them. Without a key, a machine sends and takes no tasks. The key does not keep others who reach the mailroom from seeing machine names and when each machine is active, or from deleting or delaying messages. See Who Can Send Tasks in Sending Tasks to Other Machines for details.
Wing decrypts each message and checks its sender, repository, and age before any agent sees it, and declines a message that fails or repeats an earlier one.
A request can't set the receiving machine's permission mode, tools, answer mode, or branch, and can't ask it to commit or push. Its task runs with the receiving machine's own permissions. Wing never commits it there, and a handoff waits there to be reviewed and committed like any other task.
Changes made on a peer come back as a patch that goes to the Review tab on the machine that sent the task, so they are reviewed and committed there like any other task's changes. A request from a peer with another repository carries no changes and brings none back, and unchecking Accept requests from other repositories in Peers... declines all of them. Files a task returns go to Review with it.

Within those limits, a peer's task can do anything the receiving machine's permissions allow. Set File Tasks As to Draft in Peers... to read each request before it runs. The mailroom key is a password: anyone who has it and can write to the mailroom can send tasks, and anyone who has it and can read the mailroom can read the tasks and patches in it. For a mailroom on an ssh host, a dedicated key authorized only on that host is safer than a personal key loaded into ssh-agent.

Review the Agent's Work

Reviewing AI-generated changes is an essential part of the safety picture. No matter how carefully the environment is configured, the agent can still produce code that is incorrect, insecure, or that does not meet your standards.

Use Wing's review feature before committing. When the agent finishes a task, click the Review button or configure Auto-Start Review in Project Properties to automatically review changes. Wing's diff viewer lets you inspect every change, add comments, revert individual hunks, and approve or request further work before anything is committed. See Reviewing Changes for details.
Use your team's code review process. In most development environments, AI-generated code should go through the same review process as human-written code — pull requests, code review by teammates, and CI checks. AI tools can assist with code review as well, but human oversight remains important.
Run tests. Ask the AI agent to write and run unit tests as part of every task. Review the tests themselves to ensure they actually verify the behavior you expect, not just that the code runs without errors.
Check for security issues. AI-generated code can contain security vulnerabilities just as human-written code can. Pay particular attention to input validation, authentication, authorization, and handling of sensitive data in AI-generated code.