iOS: the alert-unrecognized warning of `open --launch-url` says to `alert accept`, which grants App Tracking Transparency when that is the alert

从 packages/daemon/src/sessions/session-lifecycle/internal/session-open-execution.ts 中的 launchConfirmationUnansweredWarning 开始，然后检查 issue 引用的 open 帮助内容和 website/docs/docs/commands.md 中的相关段落。更新 alert-unrecognized 的指导，使调用方先检查警报，并根据其标题决定是否接受。三处来源都不再建议对无法识别的警报使用 alert accept 时，即为完成；可选结果字段属于额外范围。

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 get before answering it with alert 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 open help and commands.md are unchanged in 0.21.30, 0.21.31 and on main (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 in confirmation. 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

• open exited 0 with launchConfirmation: "unanswered", launchConfirmationReason: "alert-unrecognized" and the warning above in 9 runs out of 9, 4 of them at the largest Dynamic Type size.
• alert get returned the title of the App Tracking Transparency prompt.
• alert accept, as the warning says, recorded auth_value 2 (allowed). alert dismiss recorded 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

1. For alert-unrecognized, do not tell the caller to alert accept. Tell it to read the alert with alert get and to answer it from its title: alert accept only when it is the launch confirmation (for example, a translated Open in prompt). 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 the open help and to commands.md.
2. Optionally, return the alert's title and buttons in the open result when the reason is alert-unrecognized (for example, launchConfirmationAlert: { title, buttons }). The caller can then choose its answer without one more alert get.

Expected

The alert-unrecognized warning does not tell the caller to accept an alert that may not be the launch confirmation.

Related

• #3732 added alert-unrecognized and this warning. It tested the warning only with a translated launch confirmation (French simulator), where alert accept is the correct answer.
• #3627 / #3715: alert dismiss tapped Allow on the same App Tracking Transparency prompt (fixed).