iOS: an Xcode too old for the host macOS surfaces as 'Runner did not accept connection'
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 55/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- ios, typescript
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
[!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
- Run a macOS release newer than the installed Xcode supports (here macOS 27.2 with Xcode 26.6).
agent-device open com.apple.Preferences --platform ios --udid <sim>agent-device press 200 300 --platform ios --udid <sim>→Runner did not accept connectionorDaemon request timed out. Watchinglog 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.
- Ngôn ngữ chính
- TypeScript
- Star
- 4.9k
- Fork
- 328
- Merge trung bình
- 11 giờ 49 phút
- Pull request đã merge (30 ngày)
- 585
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của callstack/agent-device
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
callstack/agent-device#3407 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
callstack/agent-device#3353 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
callstack/agent-device#1869 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Client stop paths treat EPERM as a confirmed exit and drop state for a live companionCó thể đã có người làm @thymikee đã nhận hôm nay. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
callstack/agent-device#3540 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement needs-triage
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
callstack/agent-device#3531 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của callstack/agent-device
Issue tương tự
-
affected/v17 affected/v18 area/frontend type/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
umbraco/Umbraco-CMS#24186 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
better-auth/better-auth#11723 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area: docs difficulty: easy documentation good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Worker-Erstellung bricht langsame Git-Worktree-Checkouts nach 20 Sekunden abCó thể đã có người làm @KajoVanBuyten đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
AgentSystemLabs/agent-office#367 ·
Maintainer thường phản hồi trong vòng 1 ngày