Skip to content

Commit 194b33e

Browse files
committed
docs(open): state that open answers only a confirmation present before it sees the app
The --launch-url help and the commands page now attribute the prompt to the URL scheme owner and say a prompt that appears after open has seen the app is left for alert accept.
1 parent 9ee8358 commit 194b33e

2 files changed

Lines changed: 5 additions & 4 deletions

File tree

‎src/commands/management/app.ts‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -195,7 +195,7 @@ export const openCommandFacet = defineCommandFacet({
195195
text: {
196196
summary: 'Open an app, deep link or URL, save replays',
197197
cliDetail:
198-
'Use --platform to bind URL/deep-link opens to the target platform. For iOS simulator initial stdout/stderr, put --launch-console <path> on this open command, for example agent-device open "Agent Device Tester" --platform ios --launch-console artifacts/launch-console.log. Expo Go/dev-client shells accept host + URL, for example agent-device open "Expo Go" exp://127.0.0.1:8081 --platform ios. macOS also supports --surface app|frontmost-app|desktop|menubar. --metro-host/--metro-port/--bundle-url/--launch-url set this session\'s Metro/debug runtime hints as part of open itself (applied to the app\'s dev-server prefs and recorded as the session\'s dev-server binding), so a fresh session has them before its first reload instead of needing a throwaway reload-first call just to seed hints; a later plain metro reload in the same session reuses whichever of these were set. A fresh open without these flags clears any leftover binding from a previous same-name session; close also clears it. On an iOS simulator, an "Open in <App>?" prompt raised by --launch-url and naming the session app is accepted by open itself (data.launchConfirmation: "accepted"); a prompt naming another installed app is left on screen and open fails with details.reason launch_confirmation_foreign_app; a prompt whose name no single installed app carries is left on screen and open returns as usual. A device another session is holding refuses at once; add --wait <ms> to block up to that budget for it and only then fail with DEVICE_IN_USE naming the owning session.',
198+
'Use --platform to bind URL/deep-link opens to the target platform. For iOS simulator initial stdout/stderr, put --launch-console <path> on this open command, for example agent-device open "Agent Device Tester" --platform ios --launch-console artifacts/launch-console.log. Expo Go/dev-client shells accept host + URL, for example agent-device open "Expo Go" exp://127.0.0.1:8081 --platform ios. macOS also supports --surface app|frontmost-app|desktop|menubar. --metro-host/--metro-port/--bundle-url/--launch-url set this session\'s Metro/debug runtime hints as part of open itself (applied to the app\'s dev-server prefs and recorded as the session\'s dev-server binding), so a fresh session has them before its first reload instead of needing a throwaway reload-first call just to seed hints; a later plain metro reload in the same session reuses whichever of these were set. A fresh open without these flags clears any leftover binding from a previous same-name session; close also clears it. On an iOS simulator, when --launch-url raises an "Open in <App>?" prompt that keeps open from seeing the app, open accepts it if the URL scheme belongs to the session app (data.launchConfirmation: "accepted"); if the scheme belongs to another installed app, the prompt stays on screen and open fails with details.reason launch_confirmation_foreign_app; if no single installed app owns the scheme, the prompt stays on screen and open returns as usual. A prompt that appears after open has already seen the app is not answered; use alert accept. A device another session is holding refuses at once; add --wait <ms> to block up to that budget for it and only then fail with DEVICE_IN_USE naming the owning session.',
199199
mcpDetail:
200200
"Metro and debug runtime hints given here are recorded as the session's dev-server binding, so a later reload reuses them; a fresh open without them clears any binding left by a previous same-name session.",
201201
},

‎website/docs/docs/commands.md‎

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -78,9 +78,10 @@ agent-device fold open
7878
- `open <app> --wait <ms>` waits up to that budget for a device another session is holding instead of failing at once. The open reports each poll, then either opens the device or fails with `DEVICE_IN_USE` naming the owning session and saying the budget was spent. A wait that finds the device taken again keeps waiting for the rest of its budget, so several opens can queue on one device and none of them is refused before its budget is spent. Only session contention is waited for: a device claim held by another workspace's daemon is never retriable and returns its recovery command immediately. The wait extends the command's timeout envelope, so a long budget does not need a longer `--timeout`.
7979
- `open <url>` deep links are supported on Android and iOS.
8080
- `open <app> <url>` opens a deep link on iOS.
81-
- On an iOS Simulator, iOS can ask `Open in "<App>"?` before your app receives the URL from `open <app> --launch-url <url>`. If the prompt names your session app, `open` taps **Open** for you and its JSON data includes `launchConfirmation: "accepted"`. If no prompt appears, the response has no `launchConfirmation` field.
82-
- If that prompt names a different installed app, `open` does not answer it. The command fails with `details.reason: launch_confirmation_foreign_app`; `details.appName` and `details.foreignAppBundleId` name the app from the prompt. The prompt stays on screen: close it with `alert dismiss`, then pass a launch URL whose scheme your app handles.
83-
- If the name in the prompt belongs to no installed app, or to more than one (for example a debug and a release build with the same name), `open` cannot tell which app would receive the URL. It leaves the prompt on screen and returns as if no prompt appeared; answer it with `alert accept` or `alert dismiss`.
81+
- On an iOS Simulator, iOS can ask `Open in "<App>"?` before your app receives the URL from `open <app> --launch-url <url>`. If the URL's scheme belongs to your session app, `open` taps **Open** for you and its JSON data includes `launchConfirmation: "accepted"`. If no prompt appears, the response has no `launchConfirmation` field.
82+
- `open` answers only a prompt that is on screen when it first checks the app. A prompt that appears after `open` has already seen your app stays on screen; answer it with `alert accept` or `alert dismiss`.
83+
- If the URL's scheme belongs to a different installed app, `open` does not answer the prompt. The command fails with `details.reason: launch_confirmation_foreign_app`; `details.foreignAppBundleId` names that app. The prompt stays on screen: close it with `alert dismiss`, then pass a launch URL whose scheme your app handles.
84+
- If no installed app owns the scheme, or more than one does (for example a debug and a release build), `open` cannot tell which app would receive the URL. It leaves the prompt on screen and returns as if no prompt appeared; answer it with `alert accept` or `alert dismiss`.
8485
- `open <app> --launch-console <path>` captures launch-time stdout/stderr for direct iOS simulator app launches. It is not valid for URL opens or
8586
non-simulator targets.
8687
- `open --platform macos --surface app|frontmost-app|desktop|menubar` selects the macOS session surface explicitly. `app` is the default when an app argument is provided.

0 commit comments

Comments
 (0)