Skip to content

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

Closed

Description

@MoogyG

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

Activity

  1. thymikee commented on Oct 23, 2026

    @thymikee
    Member

    Triage: bug; actionable without more input from you. Thanks, the TCC.db readings make the harm concrete. Confirmed on main: launchConfirmationUnansweredWarning (session-open-execution.ts:171), help open and commands.md all point to alert accept for alert-unrecognized, although at that point open cannot tell a translated confirmation from the app's own alert. The fix changes all three to "read it with alert get, and accept only a launch confirmation". Returning the title and buttons in the open result is a separate maintainer call. An agent can pick this up.

  2. added a commit that references this issue on Oct 24, 2026
    ed798f9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions