Configuration

Wing provides two places to configure AI agent behavior: the AI page in Preferences for settings that apply across all projects, and the AI Agent tab in Project Properties for per-project settings. This section describes both.

Preferences

The AI page under Projects in the Preferences dialog contains the following settings:

Fix Completion Action

Controls what the agent does after completing a fix request (Fix Test, Fix Bug, Fix Warning, or a fix-type Code Action):

None -- The agent reports that the fix is complete and takes no further action. This is the default.
Auto-Start Review -- The agent automatically starts a review using Wing's review MCP after completing the fix, so you can review the changes in Wing's diff viewer before they are committed. If the review is approved, the agent commits the changes. If you request more work, the agent addresses the feedback and starts a new review.
Auto-Commit -- The agent commits the fix directly without review. Use this only if you are comfortable with the agent committing changes without manual review.

Warn on Concurrent Task Execution

When enabled (the default), Wing warns before sending a task while another is already running, since concurrently running agent sessions working on the same code may overwrite each other's changes. The warning dialog offers the choice to cancel, wait for the running task to finish, or continue anyway.

Some other AI settings are remembered as preferences, but they are set from the Tasks tool's Options menu (the ⋯ button) rather than the Preferences dialog: Show Task Session on Execute, Keep Current Queue and Session in Sync, Alert Me When Questions Arrive, Show History in Reverse Order, and Show Task IDs As. Record History is in the History Settings dialog from the same menu. See The Tasks Tool for details.

Project Properties

The AI Agent tab in Project Properties holds the per-project settings for AI agents, including what they are pre-approved to do without prompting for confirmation and how their work is committed. Wing answers the agent's permission requests from the pre-approval settings in force when a session runs in Ask For Approval mode, and gives them to agents that accept a list of allowed tools at launch. In Auto-Approve mode, the agent mostly decides for itself.

Task Scheduling

Chooses how tasks are scheduled in this project, and which of the project's two sets of permission and commit settings is in force. The set in force applies to the Fix features, every agent session and task started from Wing, the Tasks Manager's workers, and every commit:

Manual Queueing -- No Tasks Manager. You queue tasks yourself from their Q buttons, and they run interactively. The Preapprove settings, Commit Mode, and Show Summaries on this tab are in force.
Tasks Manager Agent -- The Tasks Manager schedules Ready tasks across queues, and tasks run autonomously, with their questions on the Questions tab. You can still queue tasks yourself from their Q buttons. The Permissions and Commits settings in the Manager's settings dialog are in force, so the tab hides its own Preapprove settings, Commit Mode, and Show Summaries and shows a one-line summary of the Manager's settings instead. The Settings... button opens the Manager's settings, which can be prepared there before the Manager is turned on.

The other settings on the tab apply with either choice. A permission request's Always Allow answer is recorded in the set in force.

This is the same switch as Use Tasks Manager Agent in the Tasks tool's Options menu: changing either one changes the other. The first time you choose Tasks Manager Agent, Wing asks for the Manager's settings. Whether the Manager is running or paused is controlled separately, from its bar on the Execute tab of the Tasks tool.

Preapprove Edits For

This controls which directories the agent may edit files in without asking for permission each time:

All Project Directories -- the agent may edit any file in the project's source directories, as long as those directories are under version control. This is the default.
Only These Directories -- the agent may only edit files in the specified list of directories, as long as those directories are under version control. When this option is selected, the Approved Directories field below becomes available for specifying the list.
Nothing (Prompt Each Time) -- the agent must ask for permission before every file edit.

Only directories under version control are pre-approved, regardless of which option is selected. This ensures that all changes made by the agent can be reviewed and reverted using your version control system.

Approved Directories

This field is shown when Preapprove Edits For is set to Only These Directories. Enter the directories that the agent may edit files in. Only directories that are under version control will actually be pre-approved.

Preapprove Running Commands

When this is enabled, the agent may run shell commands without asking for permission. When disabled (the default), the agent must ask before running each shell command.

Preapprove Revision Control Commands

When this is enabled, the agent may run revision control commands (such as hg or git) without asking for permission. The VCS type is auto-detected from the project's source directories. When disabled (the default), the agent must ask before running each VCS command.

Testing Regimen

This controls how aggressively the agent writes and runs unit tests during your workflow. The chosen regimen is compiled into the guides in the .wing directory, which every agent reads, so each session started from Wing uses a policy tailored to your preferences.

The regimens are heuristics that trade thoroughness for developer-loop speed. The "new and stale" option in particular uses recorded code-coverage data to estimate which tests a change might affect -- fast, but inherently approximate. Coverage records only what past test runs actually executed, so tests that haven't been run recently, tests whose coverage has drifted since they last ran, and tests whose code paths the tracer couldn't follow (dynamic dispatch, threads, subprocesses) can all be missed by stale detection. None of the presets are a substitute for running the full test suite before a release, merge to a long-lived branch, or any other moment where thoroughness matters more than turnaround time. Plan to run all tests at those milestones regardless of which regimen you pick during day-to-day work.

None -- The agent never writes or runs tests on its own. Pick this if you run tests as part of a separate QA or release process.
Minimal (default) -- The agent writes tests when adding new code and runs the new tests at task end, but does not run tests before review or commit.
Balanced -- Same as Minimal at task end. In addition, before review and before committing without review, the agent re-runs stale tests in the directories you changed. A test is "stale" when coverage data shows your edits touched code it depends on. "In the directories you changed" keeps this to tests living alongside the files you edited (the same directory or its sibling test/ directory), rather than every test that might be affected indirectly somewhere else in the project. The new tests you just wrote aren't re-run here, since they already ran at task end.
Thorough -- At task end, runs the new tests plus stale tests in the directories you changed. Before review and before committing without review, runs all stale tests anywhere in the project (not just the directories you changed), so nothing your edits touched goes unchecked.
Obsessive -- At task end, runs every test in the directories you changed (not just the stale ones). Before review and before committing without review, runs the full project test suite. Directory-scoped means: for every file the agent modified, run all tests under the file's sibling test/ directory.
Custom -- Configure each axis individually using the four sub-settings described below.

When Testing Regimen is set to Custom, the four sub-settings below become active. They are ignored for the preset regimens.

Code Coverage During Agent-Driven Test Runs

Stale-test detection (the "new and stale" option) requires code-coverage data, so Wing collects coverage during MCP-initiated test runs whenever it is useful and cheap:

If the project's Python interpreter is 3.12 or newer with coverage.py 7.4 or newer, Wing uses sys.monitoring for tracing. The overhead is small (around 9% on in-process Python workloads), so coverage is always collected. This means stale-test detection is available immediately if you switch the regimen later -- there is no "run all tests first to build the coverage database" step.
On older interpreters, coverage tracing falls back to sys.settrace which roughly doubles wall time. To avoid this tax, Wing collects coverage only when at least one axis uses a stale option -- "Run stale tests in changed directories", "Run new & stale tests in changed directories", or "Run new and all stale tests" (the Balanced preset's review and commit axes use the first of these, or a Custom configuration with any stale axis selected). The Minimal preset is new-tests-only, so it does not trigger coverage collection on its own.

The Testing tool's own coverage display in editors is controlled by a separate Testing preference and is unaffected by the regimen.

Stale-Test Safeguard

A small edit to a heavily-imported module can transitively invalidate hundreds of tests through coverage data, far more than the change itself warrants. When a stale run would expand to a test set estimated to exceed the Max Stale Tests to Run budget (default 120 seconds, described below), Wing narrows the run to direct stale tests -- tests whose source file you actually edited, or which live in the edited file's sibling test/ directory -- and returns a note telling the agent how many indirect-stale tests it skipped and roughly how long they would take.

This budget-driven safeguard applies regardless of which stale option is in effect. The "Run new & stale tests in changed directories" option additionally scopes to direct stale tests up front, before the budget check, so it stays narrow even when the full invalidated set would have fit within the budget.

The agent surfaces that note to you and asks before re-running with the full sweep. If you confirm, it calls test_run again with force=true to bypass the safeguard. Setting force=true on its own initiative is forbidden in the policy Wing sends to the agent.

Custom: Write Tests

Whether the agent writes unit tests on its own: Only when the user asks or Always when adding new code.

Custom: Run at End of Task

Which tests the agent runs when finishing a task. Options: Don't run tests, Run new tests only, Run stale tests in changed directories, Run new & stale tests in changed directories, Run all stale tests, Run new and all stale tests, Run all tests in directories with changed files, or Run all tests in the project.

The four stale options pair up two ways: scoped to the directories you changed versus everywhere in the project, and stale-only versus also running the new tests you wrote. A test is "stale" when coverage data shows your edits touched code it depends on.

Run stale tests in changed directories runs only stale tests, and only those that live alongside the files you edited (the same directory or its sibling test/ directory). It does not run the new tests you just wrote -- use it at a stage where those already ran, such as before review or commit when the task-end axis ran them.
Run new & stale tests in changed directories uses the same changed-directory scope but also runs the new tests you wrote, so it works as a single self-contained check.
Run all stale tests runs every stale test anywhere in the project, not just those in the directories you changed, but still skips the new tests you just wrote. In a large project even a small edit can make a great many tests stale, so reach for this only when thoroughness matters more than turnaround.
Run new and all stale tests is the project-wide scope plus the new tests you wrote -- the most thorough stale option.

Custom: Run Before Review

Which tests the agent runs before handing changes off for review. Same options as above.

Custom: Run Before Commit (without review)

Which tests the agent runs before committing without a review step. Same options as above.

Max Stale Tests to Run (seconds)

Maximum estimated runtime of stale tests the MCP test runner may execute automatically when run_stale=true. Default 120. When the invalidated set would exceed this budget, the runner executes only a prefix that fits -- preferring tests co-located with recent edits and cheapest-first -- and reports the skipped remainder so the user can opt in via force=true. Applies to every Testing Regimen (including the presets), since it controls runtime cost rather than which tests are eligible. Set to 0 for "always ask before running stale tests".

Commit Mode

Controls who performs commits, and whether the agent commits on its own as it works. This is used with Manual Queueing. With Tasks Manager Agent, the Manager's Commits in sessions you start setting, which has the same choices, is used instead.

The three The agent commits ... values are agent-driven: the agent calls vcs_commit using the queue's scoped file list and a commit message it composes itself from the work it just did. They differ only in when the agent may start a commit without being asked:

The agent commits only when asked (default) -- It never commits on its own, only when you start a review and approve it, or use the Commit link. This matches how Wing behaved in earlier releases.
The agent commits after each task -- It commits autonomously at the end of each completed task whose tests pass, scoped to the files that task changed, without waiting for you to ask.
The agent commits at its discretion -- It commits autonomously at the logical stopping points it chooses, deferring when work is incomplete, tests fail, or problems are unresolved.

The other two modes have Wing perform the commit instead. They are always user-initiated -- the agent never commits on its own in these modes:

Wing commits with generated message -- Wing performs the commit itself in the IDE process using the assembled summaries verbatim, and tells the agent the commit is already done. The agent acknowledges and stops without a follow-up tool call. Skips the agent commit round-trip entirely, but means the message is not refined by the agent before the commit happens.
Wing presents commit message for review -- Wing opens its standard VCS commit dialog scoped to the queue's files, with the assembled summaries pre-filled in the message editor. You review and edit the message, then click Commit. The agent acknowledges and stops without performing the commit. Use this mode if you prefer to write your own commit messages or want to review the change set in Wing's commit UI before each commit.

In the two Wing-driven modes the commit message is assembled from a short per-task summary line the agent prints at the end of each task, which keeps the message terse rather than dumping the full transcript. The assembled draft lives at .claude/wing-state/commit-msg-<queue_id>.draft during the queue's lifetime; .claude/ is gitignored as a whole, so it stays out of VCS. It is also handed back to the agent after an approved review in the agent-driven modes, so a commit made from a fresh or resumed session has something to work from -- but only when summaries are being collected at all, which is what Show Summaries below controls.

The Commit link in the Tasks tool follows the same setting: in the Wing presents commit message for review mode it opens the VCS commit dialog with the assembled summaries pre-filled; in every other mode it commits with no dialog (the agent performs the commit in the agent-managed modes, Wing in the Wing commits with generated message mode). In all cases the link is scoped to the queue's files and bypasses the review step.

Show Summaries

Controls whether the agent is asked to end each task with a one-line Summary: of what changed. Wing parses those lines and assembles them into the queue's commit message.

Only if Needed by Commit Mode (default) -- The agent is asked for a summary only in the two Commit Modes where Wing itself builds the commit message (Wing commits with generated message and Wing presents commit message for review). In the three agent-driven modes the agent writes its own commit message from the work it just did, so nothing reads the summary back and asking for one only spends tokens on every task.
Always -- The agent is asked for a summary on every task, whatever the Commit Mode. Use this if you want the summaries themselves -- they are recorded with the task and shown in the Tasks tool -- or if you want an assembled draft available to hand back to the agent after an approved review.

The setting is compiled into the guides in the .wing directory, so like Commit Mode it applies to new sessions only. It is used with Manual Queueing. With Tasks Manager Agent, summaries are asked for only in the two Wing-driven modes of the Manager's Commits in sessions you start setting.

When a summary is asked for and the agent ends a task without one, Wing asks again. With Claude Code this is free: a Stop hook blocks the end of the turn and the agent adds the line before finishing. Every other agent is asked in a follow-up prompt after the fact, which costs a turn -- and Wing skips even that if the agent has already been given the next task, in which case that task's summary is simply missing from the draft.

Commit Language

Sets the language agents write commit messages in, along with the task summaries that Wing builds commit messages from. Agents write their other replies, notes and questions to you in the language set by the User Interface > Display Language preference, whatever this setting is.

Use Display Language (default) -- Commit messages are in the display language. The button to the right of the popup opens that preference.
English, Deutsch (German), and the other languages listed -- Commit messages are in that language.
Other -- Commit messages are in the language whose name you type into the field shown below the popup.

The Summary: keyword, code, and code comments stay in English in every case. Like Commit Mode, this setting is compiled into the guides in the .wing directory and applies to new sessions only.

Sessions and Policy Changes

Testing policy and the Commit Mode commit policy are written into the guides in the .wing directory when the setting is changed, when the Tasks Manager is turned on or off, and when its settings are saved. An agent reads those at session start, so changes apply to new sessions only -- sessions already running keep the policy they had when they started. If you want an in-progress session to pick up a changed testing regimen or commit policy, end the session and start a new one.

How Pre-Approval Works

The pre-approval settings in force, from this tab or the Tasks Manager's Permissions, reach the agent in a way that depends on the agent, and the AI Agent tab says which case applies to the one your project uses:

Claude Code -- they are written to .claude/settings.local.json as permissions.allow entries when it starts, so changes take effect only when it is restarted.
OpenCode -- it configures its permissions rather than asking, so Wing passes these settings to it in the environment when a session starts. Nothing is written to your project. If your own OpenCode configuration sets permissions, that wins and these settings do not govern that project.
Codex -- it treats the project directory as trusted and does not ask before editing files in it or running commands, so these settings do not apply to it. They still apply to any other agent you run in the same project. Codex does still ask about files outside the project and about network access, on its own terms.
Cursor -- it asks in its own interface, where you answer it. Its ACP version, Cursor ACP, asks Wing, which answers from these settings, except about changing files: it does not ask before an edit, including outside the project, so the edit pre-approvals do not reach it and Wing warns about that before an Ask For Approval task starts. Use Plan to have it look at code without changing anything.
goose and other ACP agents -- agents run over the Agent Client Protocol (ACP) ask Wing each time they want to do something. Wing answers from these settings as they stand, so a change applies to sessions already running. See Setting Up an AI Agent for the ACP versions of agents.

The pre-approval settings only control whether agents can edit files and run shell commands without prompting. Regardless of these settings, Wing always tries to pre-approve reading project files and using Wing's MCP tools for testing, debugging, and VCS. However, some agents may ignore these instructions and still prompt to read project files or use Wing's MCPs.

The exceptions are Wing's MCP tools that write files, create_tracked_file and edit_scope, which follow the file-edit pre-approval instead. When it is Nothing (Prompt Each Time) the agent asks before using them. Otherwise, agents that ask Wing (over ACP) are pre-approved only for files in the pre-approved directories, while agents run in a terminal are pre-approved for these tools wherever the file is.

Interaction with the Run Mode

The per-task run mode (see The Tasks Tool) picks how much the agent may do without asking on each new session. The project-level pre-approvals above are layered on top of whichever mode is chosen:

In Plan, the agent cannot modify files regardless of what is pre-approved. The pre-approvals are effectively inert for that run.
In Ask For Approval, the pre-approvals are the whole of what does not prompt. This is where they matter most.
In Auto-Approve, the agent decides for itself, so the pre-approvals mostly do not come into it. On Claude Code its safety classifier still respects narrow allow-list entries (specific directories, or Bash(hg *) style command patterns) but drops blanket Bash approvals in favour of its own judgement.

Auto-Approve Requirements on Claude Code

Claude Code's auto permission mode, which is what Auto-Approve selects there and the default for a new task, requires a Claude Max, Team, or Enterprise account running a recent, sufficiently capable Claude model. Other accounts, or sessions using one of the lightweight models, will see Claude Code exit with an error at launch. If that affects you, choose Ask For Approval when dispatching tasks.

Project Settings Changed by Agents

Agents can read and change some of the project's settings with the project_get and project_set tools on Wing's wing-review MCP server. An agent changes a setting when you ask it to or its task needs it, for example to add a new package's directory to the project. Wing makes the change as if you had made it in Project Properties.

An agent can change these settings:

main_entry_point -- The Main Entry Point property: a Python file in the project, one of its named entry points, or none.
named_entry_points -- Adds a named entry point for a Python file in the project, changes its file, run arguments, or launch configuration, or removes it. A named entry point added by an agent uses the project's environment unless the agent gives it a launch configuration.
file_launch -- The run arguments and launch configuration a file uses when it is debugged or executed, as set under the Debug/Execute tab in File Properties. This includes the main entry point's file.
launch_configurations -- Adds a launch configuration, changes its run arguments, Initial Directory, Environment, Python Executable, Python Path, or Python Options, or removes it once no file or named entry point uses it.
project_environment -- The Python Executable, Python Path, Python Options, Environment, and Initial Directory properties in Project Properties. Environment values set by an agent are added to the environment Wing inherited at startup.
project_directories -- Adds a directory under the project's home directory to the project, removes one, or excludes a file or directory within one.
test_file_patterns -- Adds or removes one of the Test File Patterns under the Testing tab in Project Properties. See Project Test Files for details.
test_framework -- The Default Test Framework property under the Testing tab in Project Properties: pytest, unittest, doctest, djangotest, or nose.

Agents may set up and fix the environment your code runs in, for example when new work needs another package on the Python Path. Some settings remain yours to change:

The Build Command property and a launch configuration's build command.
Shared launch configurations, which agents can read but not change.
A Python Executable that runs on a remote host, in a container, or in a cluster. On a remote project, agents also cannot set a launch configuration's Python Executable.

Run arguments apply only to a file or named entry point that uses the project's environment. When one uses a launch configuration, the agent changes the arguments in that launch configuration instead.

project_set follows the Preapprove Edits For setting described above. When it is Nothing (Prompt Each Time) the agent asks before each change. Otherwise changes are pre-approved.

When an agent changes a setting while working on a task, the task's report on the Review tab lists the change under Decisions, with the setting's old and new values. Its Revert link puts back what that change altered and nothing else, and the Decision is then marked as reverted. Revert is offered only until the project is closed or Wing is restarted. After that, use Revise... to ask the agent to change the setting back. See The Tasks Tool for details.