Repository navigation
iOS: the alert-unrecognized warning of open --launch-url says to alert accept, which grants App Tracking Transparency when that is the alert #3921
Description
Summary
On an iOS simulator, open --launch-url recognizes only the English Open in “…”? confirmation with the Cancel and Open buttons. For any other alert, it exits 0 with launchConfirmation: "unanswered", launchConfirmationReason: "alert-unrecognized", and this 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 getbefore answering it withalert accept.
agent-device help open gives the same next step: "in both cases inspect the warning and answer with alert get then alert accept". So does commands.md: "Inspect with alert get, then answer with alert accept."
But an alert that open does not recognize is not always the launch confirmation. In our runs, it was the App Tracking Transparency prompt that the app shows at launch (Allow “<app>” to track your activity…). An agent that follows the warning taps Allow, and the simulator's TCC.db records auth_value 2 (allowed) for kTCCServiceUserTracking. The agent gets no signal that it granted a permission, and every later check that depends on the tracking answer is wrong.
Environment
- agent-device 0.21.29 (measured). The warning, the
openhelp andcommands.mdare unchanged in 0.21.30, 0.21.31 and onmain(b08b5e7). - Xcode 27.1, iPhone 17e simulator on iOS 27.0, English locale.
- Expo development build, with a custom URL scheme that the app owns. The app shows the App Tracking Transparency prompt at launch.
- The app had already received a deep link on this simulator, so iOS did not show the
Open inconfirmation. The tracking answer was reset before each run.
Steps
xcrun simctl privacy "$SIM" reset all <bundle-id>
npx agent-device open <bundle-id> --launch-url "<scheme>://..." --platform ios --udid "$SIM" --relaunch --json
npx agent-device alert get --platform ios --udid "$SIM"
npx agent-device alert accept --platform ios --udid "$SIM" # the step that the warning gives
sqlite3 ~/Library/Developer/CoreSimulator/Devices/"$SIM"/data/Library/TCC/TCC.db \
"select auth_value from access where service='kTCCServiceUserTracking' and client='<bundle-id>'"Results
openexited 0 withlaunchConfirmation: "unanswered",launchConfirmationReason: "alert-unrecognized"and the warning above in 9 runs out of 9, 4 of them at the largest Dynamic Type size.alert getreturned the title of the App Tracking Transparency prompt.alert accept, as the warning says, recordedauth_value2 (allowed).alert dismissrecorded 0 (denied).
Cause
answerLaunchConfirmation returns alert-unrecognized for every alert that isLaunchConfirmation rejects. At that point, open does not know whether the alert is a launch confirmation in another language or a different alert. But launchConfirmationUnansweredWarning gives alert accept as the answer in both cases.
The title and the buttons that open read go only to the warn diagnostic ios_launch_confirmation_unanswered. serializeOpenResult does not return them, so a --json caller must run alert get to know which alert it is.
Suggested fix
- For
alert-unrecognized, do not tell the caller toalert accept. Tell it to read the alert withalert getand to answer it from its title:alert acceptonly when it is the launch confirmation (for example, a translatedOpen inprompt). Any other alert, such as a permission prompt, is the app's own alert, and the caller answers it on its own terms. Apply the same change to theopenhelp and tocommands.md. - Optionally, return the alert's title and buttons in the
openresult when the reason isalert-unrecognized(for example,launchConfirmationAlert: { title, buttons }). The caller can then choose its answer without one morealert get.
Expected
The alert-unrecognized warning does not tell the caller to accept an alert that may not be the launch confirmation.
Related
- fix(ios): report the alert's own title and surface an unanswered launch confirmation #3732 added
alert-unrecognizedand this warning. It tested the warning only with a translated launch confirmation (French simulator), wherealert acceptis the correct answer. - iOS: alert dismiss taps "Allow" on the App Tracking Transparency prompt #3627 / fix(ios): alert dismiss picks a listed decline, never a guessed one #3715:
alert dismisstappedAllowon the same App Tracking Transparency prompt (fixed).
Activity
thymikee commentedon Oct 23, 2026
Triage: bug; actionable without more input from you. Thanks, the
TCC.dbreadings make the harm concrete. Confirmed on main:launchConfirmationUnansweredWarning(session-open-execution.ts:171),help openandcommands.mdall point toalert acceptforalert-unrecognized, although at that pointopencannot tell a translated confirmation from the app's own alert. The fix changes all three to "read it withalert get, and accept only a launch confirmation". Returning the title and buttons in theopenresult is a separate maintainer call. An agent can pick this up.fix(open): stop telling callers to accept an unrecognized iOS alert (#…