iOS: on a non-English Simulator, the `Open in` launch confirmation can be answered only by tapping coordinates: `alert accept` refuses its label and reads refuse the app that is not running

Start with RunnerAlertButtonChoice.swift, launch-confirmation.ts, and the alert command handling to trace how button labels are matched and how launch confirmations are detected. Read the related guidance in commands.md and inspect the APP_NOT_RUNNING refusal and alert tests. Done means a caller can select a uniquely matching button by its exact label on a system alert while the app is stopped, with missing or duplicate labels refused and the relevant guidance updated.

Summary

On an iOS simulator set to a non-English language, the Open in “<App>”? launch confirmation that open --launch-url raises cannot be answered with any agent-device command except a press at screen coordinates:

• open reports it as expected: launchConfirmation: "unanswered", launchConfirmationReason: "alert-unrecognized", and a warning that says to answer it with alert accept. commands.md gives the same step for "a non-English Simulator".
• alert accept refuses it with ALERT_BUTTON_NOT_FOUND, because the button label (Ouvrir in French) is not in the English label list. This refusal is intended since #3715.
• The documented way to answer an alert with unrecognized labels, "read the labels with alert get, then press the button by label through snapshot + press @ref" (commands.md), does not work either: the confirmation keeps the app from starting, and snapshot and find refuse with APP_NOT_RUNNING. Their hint again says to answer with alert accept.

So every step that the warning, the hints and the docs give ends in a refusal. The agent can continue only if it takes a screenshot, reads the button position, and taps the coordinates.

We do not ask alert accept to guess a localized button. We agree with the reason in #3715: a guessed tap can record a permission. We ask for a way to name the button explicitly (see Suggested fix).

Environment

• agent-device 0.21.30. RunnerAlertButtonChoice.swift, launch-confirmation.ts and the APP_NOT_RUNNING refusal are the same in 0.21.31 and on main (b08b5e7). On 0.21.29, one run gave the same open, alert accept and find text results (snapshot -i was not run).
• macOS 26.6.2, Xcode 27.1, Node 24.22.1.
• New iPhone 17e simulator on iOS 27.0, language fr-FR and locale fr_FR (defaults write -g AppleLanguages / AppleLocale, then a reboot).
• Expo development build installed with xcrun simctl install. Its URL scheme is not pre-approved, so iOS shows the confirmation on the first deep link.

Steps

npx agent-device open <bundle-id> --launch-url "<scheme>://..." --platform ios --udid "$SIM" --relaunch --json
npx agent-device alert get --platform ios --udid "$SIM" --json
npx agent-device alert accept --platform ios --udid "$SIM" --json   # the step that the warning gives
npx agent-device snapshot -i --platform ios --udid "$SIM" --json    # the documented fallback for unrecognized labels
npx agent-device find text "Ouvrir" click --platform ios --udid "$SIM"
npx agent-device press 268 451 --platform ios --udid "$SIM"         # position of "Ouvrir", read on a screenshot

Results

• open: exit code 0, launchConfirmation: "unanswered", launchConfirmationReason: "alert-unrecognized", warning: "iOS shows an alert this open did not recognize (alert-unrecognized), so it left the launch URL unconfirmed. Inspect the current alert with alert get before answering it with alert accept."
• alert get: message: "Ouvrir dans « Modèle RN » ?", items: ["Annuler", "Ouvrir"].
• alert accept: exit code 1, ALERT_BUTTON_NOT_FOUND, "alert accept button not found", details.dispatched: "no".
• snapshot -i and find text "Ouvrir" click: exit code 1, runnerErrorCode: APP_NOT_RUNNING, "app '' is not running", hint: "Reads do not launch the app. Relaunch it with open; if a system prompt such as a deep-link confirmation holds its launch, answer it with alert accept."
• press 268 451: Tapped. After that, alert get returned alert not found and appstate returned runningForeground.

Cause

• The runner selects the button only from English patterns: RunnerAlertButtonChoice (^open$, ^cancel$, …). This is intended (#3715).
• open recognizes the confirmation only from its English title and buttons: LAUNCH_CONFIRMATION_TITLE and isLaunchConfirmation. On a non-English Simulator, this gives alert-unrecognized, as #3732 measured.
• Reads do not activate an app that is not running, so that they do not drop the URL that the confirmation holds (notRunningRefusal, #2852). Thus snapshot and press @ref cannot reach the confirmation.

Each of these rules is correct alone. Together, they leave the alert commands, which do reach the confirmation, as the only way to answer it, and those commands only accept English labels.

Suggested fix

1. Let the caller name the button: for example alert accept --button "<label>" and alert dismiss --button "<label>", or alert press "<label>". The runner activates the button whose label is exactly the given text, through the same alert path as alert accept, so it also works on a SpringBoard alert when the app is not running. It refuses with ALERT_BUTTON_NOT_FOUND when no button or more than one button has that label. Nothing is guessed: the caller reads the labels with alert get and chooses one.
2. Point the alert-unrecognized warning, the APP_NOT_RUNNING hint, the ALERT_BUTTON_NOT_FOUND hint, help alert and commands.md to that option when the labels are not English.

The same option also helps with app alerts. On the App Tracking Transparency prompt on a French simulator (Xcode 27.1, iOS 27.0), alert dismiss (0.21.29 and 0.21.30) and alert accept (0.21.29) also refuse with ALERT_BUTTON_NOT_FOUND. There, the app is running, so snapshot -i and find text "Demander à l’app de ne pas me suivre" click work, but each localized alert costs a screenshot and a lookup of the label.

Expected

On a non-English Simulator, an alert command answers the launch confirmation and other system alerts with a button that the caller names, without screen coordinates and without a guessed tap.

Related

• #3921: the alert-unrecognized warning says to alert accept. Its suggested fix keeps alert accept for a translated Open in prompt, which this issue shows is refused.
• #3732: added alert-unrecognized; its live test on a French simulator saw this confirmation reported as unanswered.
• #3627 / #3715: alert dismiss refuses unknown and localized labels instead of guessing.
• #2852: reads refuse an app that is not running.