Cold iPhone startup ignores the requested preparation deadline

[PrinceD96]

Description

A never-booted iPhone Simulator can require longer than the fixed internal boot wait to complete Apple's first-boot data migration. Increasing the public prepare timeout does not extend that internal wait. This prevents unattended cold-device startup even though the simulator eventually finishes booting successfully.

Steps to reproduce

1. Create a new iPhone 17 Simulator with an installed iOS runtime, without booting it first.
2. In an isolated CLI state directory, run:
   agent-device prepare ios-runner --platform ios --udid <fresh-iphone-udid> --timeout 240000 --json
3. On a first boot whose migration exceeds 120 seconds, observe the internal simctl bootstatus timeout before the requested command deadline.
4. Observe the same target with read-only xcrun simctl bootstatus <fresh-iphone-udid> without -b. After initialization completes, runner preparation can succeed.

The duration is host-dependent; a fast first boot may not reproduce this.

Expected behavior

An explicit startup budget should reach the simulator boot and runner preparation stages. Opening a cold simulator should retain its existing host-global claim continuously through startup into the established session, so a second workspace cannot acquire the same target while the first is initializing it.

Actual behavior

With agent-device 0.20.10, the preparation path hit a 120-second internal bootstatus timeout despite --timeout 240000. A fresh iPhone's first-boot migration took approximately 4 minutes 42 seconds. Retrying preparation after boot completion succeeded in approximately 16 seconds. An earlier retry while startup was still in progress also failed, so blindly retrying is not a reliable provisioning workflow.

Ordinary open has a shorter request budget, while prepare owns only a transient claim. Splitting initialization across failed prepare requests and a later open therefore does not provide a continuous task-long claim.

Environment

• agent-device: 0.20.10
• Target: newly created iPhone 17 Simulator, iOS 26.5 runtime
• Local macOS/Xcode simulator workflow, multiple independent workspace sessions
• Current follow-up host: macOS 26.6.2, Xcode 26.6, Node.js 24.15.0. The initial observation was made before this follow-up environment check.

No application installation or application-specific behavior is required to reproduce the boot wait.

Proposed boundary and acceptance criteria

Proposed CLI shape, not an existing supported open option:
agent-device open Settings --platform ios --udid <fresh-iphone-udid> --timeout 600000 --json

• A caller-selected startup deadline propagates through request handling, simulator readiness, and required runner startup; an internal fixed 120-second cap must not preempt a longer explicit budget.
• Existing host-global claim ownership is retained from initial acquisition through successful open. No second ownership mechanism or release/reacquire gap is introduced.
• A competing workspace receives DEVICE_IN_USE throughout cold startup and the subsequent active session.
• Deadline expiry and cancellation are bounded, preserve structured diagnostics/progress, and finish owned cleanup before releasing the claim.
• Regression coverage proves deadline propagation, contention, cancellation, and cleanup; a real never-booted iPhone verifies the local CLI end to end.

Related work

#2307 centralizes request/teardown budget calculation but describes preserving current arithmetic and behavior. #2308 and #2312 concern managed lease admission. This report concerns ordinary local iPhone startup and should reuse those existing ownership/budget boundaries where applicable, not duplicate managed allocation or workspace pinning.

Searched open issues and PRs for boot, bootstatus, first boot, migration, startup, and timeout; no matching cold-boot deadline report was found.