Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

iOS: an Xcode too old for the host macOS surfaces as 'Runner did not accept connection'

Geschlossen
#3,449 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@thymikee arbeitet bereits daran.

Seit 16.10.2026.

  • #3739 von @thymikee — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
ios, typescript
Bereich
mobile, testing

Rechercherichtung

Read runner-error-classification.ts and runner-dev-tools-security.ts, then trace how runner startup failures are classified and whether retries are triggered. Reproduce with an Xcode version incompatible with the host macOS and inspect runner.log for the service hub failure. Done when this failure gets the proposed actionable reason and update hint without retrying.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement in-progress ready-for-agent

[!NOTE]
🤖 Opus 5.5 on behalf of Oliver

Summary

On a Mac whose Xcode is too old for its macOS, every iOS Simulator interaction (press, snapshot -i) fails with Runner did not accept connection or Daemon request timed out. The real cause is in runner.log, but the returned error doesn't mention it, so agents retry and then guess at the cause (SSH sessions, permissions).

Seen with macOS 27.2 (26B5101f), Xcode 26.6 (17F113), an iOS 26.5 simulator, and agent-device 0.21.23. open and screenshots kept working. Installing Xcode 27.0 fixed it without other changes.

What happens

runner.log repeats this for every xcodebuild test-without-building attempt, until ** BUILD INTERRUPTED **:

iOSSimulator: … unable to connect to "com.apple.instruments.deviceservice.lockdown"
(Error Domain=DVTiPhoneSimulatorErrorDomain Code=-1 "DTServiceHubClient failed to bless service hub for simulator <name> (<udid>)"
UserInfo={… NSUnderlyingError=… {Error Domain=DTServiceHubClient Code=1 "'localDeviceConnectionWithError:' failed but didn't provide an error."}})

The kernel log at the same moment shows why. macOS refuses to load Xcode's DTServiceHub:

AMFI: When validating /Applications/Xcode.app/Contents/SharedFrameworks/DVTInstrumentsFoundation.framework/Versions/A/Resources/DTServiceHub:
  dynamic: com.apple.DTServiceHub disallowed without correct com.apple.private.amfi.version-restriction entitlement version
proc …: load code signature error 4 for file "DTServiceHub"

The same failure happened over SSH and inside the logged-in GUI session (DevToolsSecurity was disabled; I did not test it enabled). The CLI said the runner had already been restarted once during the request, and the retry failed the same way.

Repro

  1. Run a macOS release newer than the installed Xcode supports (here macOS 27.2 with Xcode 26.6).
  2. agent-device open com.apple.Preferences --platform ios --udid <sim>
  3. agent-device press 200 300 --platform ios --udid <sim> → Runner did not accept connection or Daemon request timed out. Watching log stream --predicate 'eventMessage CONTAINS "DTServiceHub"' during the press shows the AMFI lines above.

Proposal

Would you take a change that recognizes this as its own runner startup failure? Something like failed to bless service hub in runner.log → reason "Xcode cannot start its simulator service on this macOS", hint "Update Xcode to a version that supports this macOS", without retrying. runner-error-classification.ts and runner-dev-tools-security.ts look like the natural home.

A cheaper preflight is possible too, if you'd rather fail fast: macOS kills DTServiceHub --help with SIGKILL at launch in this state, while a working Xcode exits it normally with status 1. That ties agent-device to Xcode's internal file layout, though, so classifying the log seems safer.

Context: T3 Code installs agent-device on remote Mac hosts for its agents, which is where we hit this. We're happy to send a PR if this direction works for you.

Vorherrschende Sprache
TypeScript
Sterne
5.1k
Forks
339
Ø Merge
12 Std. 50 Min.
Gemergte PRs (30 T.)
632

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus callstack/agent-device

Alle Issues in callstack/agent-device

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.