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 Claude Code does after completing a fix request (Fix Test, Fix Bug, Fix Warning, or a fix-type Code Action):

None -- Claude Code reports that the fix is complete and takes no further action. This is the default.
Auto-Start Review -- Claude Code 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, Claude Code commits the changes. If you request more work, Claude Code addresses the feedback and starts a new review.
Auto-Commit -- Claude Code commits the fix directly without review. Use this only if you are comfortable with Claude Code 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 Claude Code instances 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.

Raise Claude Code on Execute

When enabled (the default), Wing automatically raises the Claude Code tool and switches to the correct instance when a task starts running. This setting is also exposed as a checkbox in the Tasks tool's Options menu.

Track Queue Changes in Claude Code

When enabled, Wing keeps the current queue on the Execute page in sync with the current Claude Code instance: selecting a queue raises the Claude Code instance bound to it, and switching instances in the Claude Code tool selects the matching queue. Disabled by default, since it pulls focus away when you are just glancing at a queue's task list or at another Claude Code instance. Also available from the Tasks tool's Options menu.

Show History in Reverse Order

When enabled (the default), the History tab shows the most recent completed tasks first.

Record History

When enabled (the default), completed tasks are archived to the History tab. When disabled, completed tasks are discarded, the History tab is hidden, and the history-related entries in the Options menu and History Settings dialog are grayed out.

Enable Legacy AI Features

When enabled, Wing shows the legacy AI features (AI Coder, AI Chat, AI Suggestions) in the user interface alongside the Claude Code agent features. When disabled (the default), only Claude Code features are shown.

Project Properties

The AI Agent tab in Project Properties controls what Claude Code is pre-approved to do without prompting for confirmation. These settings affect the Fix features and any Claude Code session started from Wing.

Preapprove Edits For

This controls which directories Claude Code may edit files in without asking for permission each time:

All Project Directories -- Claude Code 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 -- Claude Code 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) -- Claude Code 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 Claude Code 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 Claude Code may edit files in. Only directories that are under version control will actually be pre-approved.

Preapprove Running Commands

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

Preapprove Revision Control Commands

When this is enabled, Claude Code 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), Claude Code must ask before running each VCS command.

Enable Legacy AI Features

This per-project setting overrides the global Enable Legacy AI Features preference for the current project. It has three options: Use Preference Setting (the default), Enable, and Disable.

Testing Regimen

This controls how aggressively Claude Code writes and runs unit tests during your workflow. The chosen regimen is compiled into .claude/CLAUDE.md as the instructions Claude follows, so each Claude Code 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 -- Claude 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) -- Claude 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, Claude 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 Claude 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 Claude-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 Claude 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.

Claude surfaces that note to you and asks before re-running with the full sweep. If you confirm, Claude 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 Claude.

Custom: Write Tests

Whether Claude 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 Claude 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 Claude runs before handing changes off for review. Same options as above.

Custom: Run Before Commit (without review)

Which tests Claude 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 Claude commits on its own as it works. The three Claude commits ... values are Claude-driven: Claude calls vcs_commit using the queue's scoped file list and a commit message Claude composes from the per-task summaries Wing accumulated as the queue ran (this works in any Claude session, including a fresh one with no per-task context, because Wing supplies the summaries). They differ only in when Claude may start a commit without being asked:

Claude commits only when asked (default) -- Claude never commits on its own. It commits only when you start a review and approve it, or use the Commit Without Review link. This matches how Wing behaved in earlier releases.
Claude commits after each task -- Claude 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.
Claude commits at its discretion -- Claude 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 of Claude. They are always user-initiated -- Claude 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 Claude the commit is already done. Claude acknowledges and stops without a follow-up tool call. Skips the Claude commit round-trip entirely, but means the message is not refined by Claude 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. Claude 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 all modes the commit message is built from a short per-task summary line that Claude prints at the end of each task (Wing prompts Claude for it via a Stop-hook backstop if missing, so the draft stays terse rather than dumping the full transcript). The 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.

The Commit Without Review 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 (Claude performs the commit in the Claude-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.

Claude Code Sessions and Policy Changes

Testing policy and the Commit Mode commit policy are written to .claude/CLAUDE.md when the setting is changed. Claude Code reads that file 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 are written to .claude/settings.local.json as permissions.allow entries when Claude Code starts. Claude Code always has permission to read files and use Wing's MCP tools (testing, debugging, and review) regardless of these settings. The pre-approval settings only control whether Claude Code can edit files and run shell commands without prompting.

Because these entries are set at launch time, changes to pre-approval settings take effect only when Claude Code is restarted.

Interaction with the Session Action

The per-task Session action (see :doc:`tasks`) picks Claude's permission mode for each launch (plan / auto / acceptEdits / default). The project-level pre-approvals above are layered on top of whichever mode is chosen:

System Message: ERROR/3 (<string>, line 322); backlink

Unknown interpreted text role "doc".

In Plan Mode, Claude cannot modify files regardless of what is in the allow list. The pre-approvals are effectively inert for that run.
In Auto Mode, Claude's safety classifier respects narrow allow-list entries (specific directories or Bash(hg *) style command patterns) but drops blanket Bash approvals in favour of the classifier's judgement.
In Accept Edits mode, Claude auto-approves all file edits regardless of the allow list. Non-edit allow entries (VCS, custom commands) still apply as pre-approvals.
In Edits Require Approval mode, the allow list is the only source of pre-approvals -- everything else prompts.

Auto Mode Requirements

Claude Code's auto permission mode (used by the default New Session -- Auto Mode session action) 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, pick a different New Session option (for example New Session -- Accept Edits or New Session -- Edits Require Approval) when dispatching tasks.