GitHub Actions · macOS · Checked November 5, 2026

xcrun simctl list takes minutes on macos-15 and macos-26: the first call waits while simdiskimaged mounts and walks the simulator runtimes

On the GitHub-hosted macos-15 and macos-26 runners (Apple Silicon), the first xcrun simctl command of a job starts simdiskimaged, which mounts the simulator runtime images. On many VMs it also walks the whole file tree of one runtime, sometimes two or three, before it mounts the rest, and the command waits for that. The first xcrun simctl list -j devices then takes up to 2.5 minutes; later calls take under 2.5 seconds (runner-images #15247, with measurements from 30 jobs per image). The image maintainers have said they will look into it.

What it looks like

Nothing fails by itself; the first simulator step is just slow. It fails when something around that call has a short time limit. One project's setup script gives xcrun simctl list devices --json 30 seconds, and on hosted macOS runners it sometimes runs out (OpenCine #111):

TimeoutExpired(['xcrun', 'simctl', 'list', 'devices', '--json'], 30)

Every simulator suite that used that script could fail before it tested anything. Test runners and build tools that list or boot simulators make the same first call, so the wait can also land inside their own timeouts. To see it in your job, time the call twice:

- run: time xcrun simctl list -j devices > /dev/null
- run: time xcrun simctl list -j devices > /dev/null

The measurements

From the report, 30 jobs per row, on runners with 3 cores and 7 GB:

macos-15 with the image's CoreSimulator 1051.17.8: 26 of 30 jobs walked a runtime; the first call took 33.7 seconds at the median, from 6.6 to 152.9 seconds.
macos-26 with the image's CoreSimulator 1051.55: 11 of 30 walked; 7.3 seconds at the median, from 5.0 to 65.9 seconds.
xcode-27 with CoreSimulator 1174.20: none walked; 4.0 seconds at the median, from 2.6 to 8.0 seconds.
With CoreSimulator 1174.9.2 installed in the job, no job walked on macos-15 (8.6 seconds at the median) or macos-26 (4.0 seconds).

So it comes with CoreSimulator 1051, the version that the Xcode 16 and Xcode 26 releases install. Which runtime is walked varies from VM to VM: iOS, tvOS, watchOS and visionOS runtimes all appear. The Intel images were not tested.

What does not help

Waiting: making the first call 3 minutes into the job, on VMs up to 13 minutes old, changed nothing. simdiskimaged does not run until the first simctl call starts it.
xcodebuild -runFirstLaunch before the call changed nothing.
Starting xcrun simctl list in the background early in the job only moves the walk earlier. The job still pays for it, and still waits if it needs simulators soon after.

Keeping it out of your timeouts

Give the first simctl call room: a limit of several minutes, or a retry, instead of 30 seconds. Do the same for the first step of any tool that lists or boots simulators.
Make the first call its own step, before the build and the tests. The wait then shows up there, with its time in the log, and not inside a test runner's timeout:
```
- name: Mount the simulator runtimes
  run: time xcrun simctl list -j devices > /dev/null
  timeout-minutes: 5
```
If you can move to Xcode 27, the xcode-27 image does not walk. It has its own catch with simulator devices (xcode-27 and the iOS 27.1 simulator).
The reporter also tried installing XcodeSystemResources.pkg from the xcode-27 image's Xcode on macos-15 and macos-26, passed between jobs through the Actions cache. That brought in CoreSimulator 1174 and removed the walk; a simulator booted and a small xcodebuild test passed with the older Xcodes. That is all they checked, so treat it as an experiment, not a fix.
Follow runner-images #15247 for a change in the images.

Telling it apart

The first simctl call is slow and the second is fast: this page.
"Unable to find a device matching the provided destination specifier": the device is not in that simulator runtime (xcode-27 runner).
"xcrun: error: unable to find utility "simctl", not a developer tool or in PATH": the selected developer directory is the Command Line Tools, not an Xcode. Select an Xcode with sudo xcode-select -s /Applications/Xcode.app.
The job stops at its time limit with "The job has exceeded the maximum execution time": maximum execution time.

See failed jobs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so the step that timed out waiting for the simulators stands out, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

Get it on JetBrains Marketplace

GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o.; Apple, Xcode and macOS are trademarks of Apple Inc. This page is not affiliated with, sponsored or endorsed by any of them.

More: xcode-27 runner · macOS 14 retired · GitHub Actions plugins for IntelliJ IDEA compared · 日本語