Xcode UI tests and what automationmodetool does and does not cover

Running Xcode UI tests in CI can stall on an authentication dialog before the run starts. On a Mac with a person in front of it, typing the password is enough. A self-hosted runner or a Mac in a test lab has nobody to type it, so the tests do not proceed.

automationmodetool is the tool that configures this authentication requirement. It does not solve every permission problem of UI tests, though. This post separates what the tool covers from what has to be handled on its own, such as TCC permissions, and goes through the order for preparing a machine. I ran the status query myself on October 4, 2026, on macOS 27.0.1 with Xcode 27.0. The commands that change the setting, and UI tests, were not run.

With no argument it reports the status

According to the man page, the tool configures a device so that Automation Mode for UI testing can be enabled without user authentication. It says this is for preparing CI machines and lab machines whose users do not have administrator privileges. With no argument, it prints whether Automation Mode is enabled and whether authentication is required, and exits. The man page installed on my Mac says the same.

automationmodetool

This is the output from running it on my Mac.

Automation Mode is disabled.
This device DOES NOT REQUIRE user authentication to enable Automation Mode.

The two lines say different things. The disabled on the first line is the current state: Automation Mode is off right now. The second line is the setting for whether authentication is needed when the mode is turned on. When it says DOES NOT REQUIRE, XCTest and testmanagerd can switch the mode during a run without a password being entered.

This command allows enabling it without authentication.

sudo automationmodetool enable-automationmode-without-authentication

This one goes back to requiring authentication.

sudo automationmodetool disable-automationmode-without-authentication

Changing the setting itself needs administrator authentication. So I recommend doing it when a machine is first prepared, not on every PR.

The authentication setting and TCC permissions are separate problems

Xcode Helper or the runner asking for Accessibility, AppleEvents, or Post Event is a TCC matter. In Apple’s PPPC settings guide, these three correspond to controlling the Mac via Accessibility APIs, sending a restricted AppleEvent to another process, and sending events with CoreGraphics APIs. automationmodetool cannot stand in for a TCC grant, an installed PPPC profile, or an Accessibility grant.

The wording in the log tells the two apart. A denial such as Xcode Helper does not have permission to use Accessibility. points to the Privacy & Security settings or the PPPC settings in MDM. Timed out while enabling automation mode. may be a problem at the authentication step, so query the status first. A timeout alone does not settle that it is an authentication problem, and the two failures can happen together. The prompt on screen is also a hint. A prompt asking for a password is a candidate for the mode authentication side, and a prompt asking for consent to control an app, or for Accessibility, is a candidate for the TCC and PPPC side.

Which process is asking for the permission can be seen in the TCC log. The command is given in the same PPPC guide.

log stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'

I recommend confirming the responsible process in this log before allowing it, and not adding Xcode.app or the app under test to the allow list on a guess.

Configure when preparing the machine, and only query in the job

Here is an example order for preparing a Mac for unattended UI tests. Select the Xcode developer directory, accept the license, run the first-launch tasks, change the authentication setting, and query the status.

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license accept
sudo xcodebuild -runFirstLaunch
sudo automationmodetool enable-automationmode-without-authentication
automationmodetool

On a self-hosted runner, be careful about putting this change into a workflow. A step like the one below is an example.

- name: Enable automation mode
  run: sudo automationmodetool enable-automationmode-without-authentication

Allowing sudo in a workflow where arbitrary code runs creates a risk of privilege escalation. I recommend a split in which the owner of the machine does the preparation and the job only builds and tests. At the start of the job, record the status without changing the setting.

- name: Show UI automation state
  run: |
    automationmodetool || true
    xcodebuild -version
    xcode-select -p

|| true keeps the job going when the query fails, so that the record is still left. This way of operating is my own reading, not something the man page prescribes.

There is an exception. Hosted CI where the service manages sudo is a different situation. The Bitrise guide says to run the change command in a Script Step when this timeout appears.

The problem has been reported several times. Issue 5410 reports UI tests failing with the timeout on the macOS 12 Monterey runner of GitHub Actions, and issue 7778 covers the same error on macOS 13 with Xcode 14.3.1. Flutter issue 166011 says that integration tests through XCUITest need this setting, and that the trouble is the setting command asking for a password. That issue quotes an approach that types the password with expect. That is fragile, so I recommend preparing the runner account and the machine in advance. Recording and replaying UI automation is the subject of WWDC25 session 344.

The per-device mode setting is separate from TCC and keychain permissions, which depend on the user, the process, and the signing. The signing keychain, Developer Tools Access, and DevToolsSecurity are also areas to look into on their own. With several Xcode versions or several runner accounts, work out which setting applies to which scope. The earlier version of this post was written against macOS 26.5.1 and Xcode 26.6, and this time only the status query was checked again. Whether the setting survives a reboot, an update, or an image replacement, and whether UI tests really pass after it is set, were not checked.