[agent-cli] An EAS Simulator scope reads its unclaimed target, not apps on local devices by vonovak · Pull Request #203 · expo/expo-agent-cli

vonovak · 2026-10-24T03:06:11Z

Every runtime command acts on the device bound to this worktree, and nothing else attached to the same dev server, and says which device it acted on.

This PR makes an EAS Simulator scope read the session's app and skip the apps that local devices run.

Stack: #202 → #203 → #204 → #206 → #217 → #218 → #207 → #200 (this is 2/8).

Problem

The app on an EAS Simulator iOS session registers under the cloud simulator's model name, for example iPhone 17. No local tool reports that name, so nothing placed the target (DF3, N2-06, N2-09). runtime:tree --ios refused with "No app connected", and smoke reported app unknown after 192 s.

Fix

On an EAS Simulator scope for iOS, or with no platform flag, a target that a local device tool names is skipped. The one target that nothing places is the session's app. While the scope's device tools give no answer, the targets stay undetermined. --eas alone is a cloud scope. An attachment wait reads the facts again for a changed list. It asks a tool that gave no answer again at most once a second, and its first read counts as the first ask.

Red tests: runtime targetSelection-test "holds every unclaimed target while the local simulators are unknown"; smoke targetSelection-test "asks a failing simctl again at most once a second while the wait polls"; preflight-test "should refuse two apps nothing places, and say how to name the session's platform"; e2e cloud-simulator-test "reloads the session's app, not the app on a booted local simulator" and "reads neither unclaimed app with no platform".

Live check: at the stack top, on an EAS iOS session (Expo Go, v2 tunnel) with a local simulator app on the same dev server: runtime:reload --eas skipped the local app as other-device and proved 2 of 2 reloads by debugger-context-replaced; runtime:reload --ios skipped the cloud app and proved 3 of 3 the same way. The live-cloud suite passed 17 of 17 at the stack top.

Watch: a session whose model name equals a booted local simulator's name is skipped as a local app.

🤖 Generated with Claude Code

Kudo · 2026-10-29T18:27:17Z

+    // device runs it, so only an answered tool can show that no local device does.
+    if (claimedLocally(target, deviceInventory)) return { group: 'other-device' };
+    if (scopeToolsUnknown(targetSelection, deviceInventory)) return { group: 'undetermined' };
+    return platform == null ? { group: 'undetermined' } : { group: 'read' };


A failed adb becomes androidModels: [] (readDeviceInventoryAsync, around line 245), and scopeToolsUnknown (line 71) only looks at bootedStatus. runAdbAsync does not throw when adb is missing: notRunnable or a non-zero exit both fail the exitCode === 0 check, same as "adb answered and nothing is attached".

An emulator target with React Native's <model> - <release> - API <sdk> name is then placed as Android without being claimed locally, so this line puts it in read. That non-empty read list blocks promotion of the one unclaimed session target (read.length === 0 at line 169). runtime:reload --eas with no platform reloads the local emulator and leaves the session app undetermined. The same targets with a successful adb devices -l skip the emulator as other-device and read the session app. adbNotRunnableError already says a failed spawn says nothing about whether a device is attached.

Do not mark the whole no-platform scope unknown when adb is missing, or a Mac without adb could not read a lone iOS session target. When adb did not answer, leave an Android-shaped target undetermined instead of read. A lone unclaimed iOS target can still be promoted. If that Android-shaped target sits beside the session target, both stay undetermined and the command refuses, which is what a failed simctl already does.

Fixed in e599a28 and c3a3948

Kudo · 2026-10-29T18:27:17Z

-  platform: NavigatePlatform
+  device: NavigateDevice
 ): Promise<(deadline: number) => Promise<number>> {
  const deviceInventory = await readDeviceInventoryAsync();


This inventory is reused on every poll, for the whole --attach-timeout. resolveTargetSelectionAsync keeps a passed inventory, so it never asks again.

The scope rule this PR adds says an attachment wait re-reads a changed target list and asks a tool that gave no answer again at most once a second, because a local simulator can boot during the wait. scopedListClassifier does that. This waiter does not, and the comment above now says the facts are read once per wait.

A simctl failure on this first read stays bootedStatus: 'unknown' for the whole budget, every cloud target stays undetermined, and navigate --eas reports not attached even after the session app is the one unclaimed target. The other way, a simulator that boots mid-wait is absent from the snapshot, so its Expo Go is not claimed locally (the app id still places it as iOS) and can satisfy the cloud attach check.

Classify this wait with scopedListClassifier, or apply the same limits here. This read can count as the first ask.

Fixed in 2c33f9c (#200)

Kudo · 2026-10-29T18:27:17Z

+    [
+      `No app connected to the Expo dev server at ${devServerUrl} could be shown to be the EAS Simulator session's app.`,
+      `Why: its debugger target list names ${apps} that nothing on this machine places. One unclaimed app is the session's only when the local device tools answered and no other app is unclaimed.`,
+      `How: run this command again with the session's platform ("--ios --eas" or "--android --eas"), and close the apps on this dev server that are not the session's.`,


With two unclaimed iOS targets, this How says to pass --ios --eas or --android --eas. The e2e reads neither unclaimed app with --ios shows --ios still reads neither. noAppOnPlatformError then says to drop --ios to read the connected app, which hits this error again.

Before this PR, no platform really did read every target, so that older How was true. It is not true for a cloud scope. The clause about closing the other apps is the part that disambiguates two iOS targets. Say that a platform flag only chooses which device tool has to answer, and point the --ios undetermined How at the same recovery instead of telling the caller to drop the flag.

Fixed in e599a28

Kudo · 2026-10-29T18:27:17Z

 /** Every booted iOS simulator in `simctl list devices booted -j`, in the order `simctl` lists them. */
 export function parseBootedIosSimulators(stdout: string): { udid: string; name: string }[] {
-  return parseBooted(stdout, (runtime) => runtime.includes('.iOS-'));
+  return parseBooted(stdout, (runtime) => runtime.includes('.iOS-')) ?? [];


parseBooted now returns null when any kept device lacks a udid or a name, so one bad entry fails the whole listing. Folding that into [] makes listBootedIosSimulatorsAsync report no booted simulator, including the valid ones beside the bad entry. A missing name used to be skipped and the rest of the list was kept.

Callers of this iOS parser now infer absence, which is what the comment on parseBootedSimulators says not to do. The cloud path is fine: it keeps null and sets bootedStatus: 'unknown'. Skip the bad device here, or surface the failure without pretending the listing was empty.

Fixed in d9d2365

…ps apps on local devices The cloud device is a value, with a null session id for a run that only has flags. Runtime reads, smoke and navigate use one cloud placement rule. On an EAS Simulator scope for iOS, or with no platform flag, a target that a local device tool names (a booted simulator, an attached Android model) is skipped. The one target that nothing places is the session's app. An Expo Go target that no booted simulator has is read. Both are read only when the device tools of the scope's platform answered, or the host cannot run them. With an unknown answer they stay undetermined. --eas with no platform flag is a cloud scope. When it holds no app, the refusal names the apps nothing places and the two platform flags. The CDP client and the attachment wait report undetermined apps for any scope that names a platform or a device. runtime:reload --method runtime reads the connection's scope. An attachment wait reads the inventory again for a changed target list, and asks a device tool of the scope's platform that gave no answer again, at most once a second, because a local simulator can boot during the wait. The read the wait starts from counts as the first. A simctl listing that is malformed, or has an entry with no name or udid, gives no inventory. parseBootedIosSimulators then returns an empty list. The rows and their tests are in llp/0005 §Which app a run reads. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The classifier rows for unclaimed apps become e2e cases: runtime:reload --eas reloads no app that nothing claims, with or without a platform, beside a booted local simulator, and a run without --eas reads no unclaimed app. Two unit duplicates go. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…Android session app With --eas and no platform, the one target nothing places was read even when an Android session's own app was already read. The session is then not iOS, so that target is not its app: it can be a development build on a physical phone. The post-pass now reads it only while nothing else is read. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…other-platform skip The two-unclaimed-targets row cites the e2e table that replaced its unit test. The platform-flag e2e case now lists an app on the other platform and asserts it is not evaluated, so the "other platform" row cites a test that checks it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The citation carried a stray backslash before the apostrophe, so it named no test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The test borrowed its describe's `cloud` target and inventory, which a later layer's trim removes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A booted local simulator exists only on macOS; on Windows the stub simctl cannot run, so the case tested nothing real there and failed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…booted iOS simulators (llp/0005 §Which app a run reads) parseBootedIosSimulators skips an entry without a udid or a name. parseBootedSimulators still returns null for it, so the cloud path stays undetermined. Unit test: a parser table over simctl JSON, which the e2e harness cannot make malformed per entry. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…t, and two unclaimed apps get a recovery that works (llp/0005 §Which app a run reads) DeviceInventory gains androidStatus. With no platform and no adb answer, an Android-shaped target stays undetermined and is never promoted, so a lone iOS session app is still read. The two-unclaimed-apps How and the --ios undetermined How now say to close the other apps and that a platform flag only chooses which device tool answers. Unit test: targetInventory-test drives the real inventory read with a mocked adb exit; the e2e harness has no adb failure stub. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ield (llp/0005 §Which app a run reads) DeviceInventory drops androidStatus. androidModels is null when adb devices -l did not exit 0, as bootedStatus covers simctl. The per-target rule is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…laced the last target list (llp/0005 §Which app a run reads) One failed simctl or adb read during an attachment wait no longer un-places an app an earlier read placed; the tool is still asked again at most once a second. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…hether every entry was valid Each wrapper decides what a bad entry means, instead of a flag that changes the parser's return. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ice tool gave no answer on it (llp/0005 §Which app a run reads) The wait, not the refresh, keeps the facts that placed the last list, and it commits the new list only once a read answered, so the next due poll asks again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…nswers On Linux and Windows the iOS facts are unsupported, not unknown, so the tests failed there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…onnection (#202) **Every runtime command acts on the device bound to this worktree, and nothing else attached to the same dev server, and says which device it acted on.** This PR gives every runtime command one decision about which apps a run reads, so each layer above changes one place. Stack: #202 → #203 → #204 → #206 → #217 → #218 → #207 → #200 (this is 1/8). ## Problem On main, each runtime caller (reads, waits, the bundle check, smoke) builds its own scope from the flags, and the device facts from simctl and adb are mixed with decisions. smoke also keeps a failed device lookup for the rest of the run, so a later phase cannot recover. ## Fix `TargetSelection` is the run's scope, `DeviceInventory` holds the device tools' facts, and one resolver classifies the targets. `RuntimeConnection` carries the classified targets, and every reader, wait and deferred command reads `classifiedTargets.read`. An attachment wait keeps the facts for an unchanged list and reads them again, within its budget, for a changed list. smoke keeps a successful device choice until a boot or a session start replaces it, and does not keep a failed lookup. The rules are in llp/0005 §Which app a run reads. Red test: smoke targetSelection-test "asks the device tools once for a list that does not change" (4 simctl calls before the fix, 1 after). Also: "retries a failed device lookup, shares concurrent discovery, and retains the successful choice". Live check: run at the stack top only, not at this layer. The local iOS simulator runs (#207, #218) and the EAS session runs (#203, #200) go through this layer's scope, classifier and inventory refresh. None of them counted device-tool calls or forced a failed lookup, so this layer's claim rests on its red tests. Watch: an unscoped wait now asks the device tools once for each changed list that holds an unplaced target. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

**Every runtime command acts on the device bound to this worktree, and nothing else attached to the same dev server, and says which device it acted on.** This PR makes runtime reads and smoke skip an app on a simulator that another worktree bound. Stack: #202 → #203 → #204 → #206 → #217 → #218 → #207 → #200 (this is 3/8). ## Problem A booted simulator that another worktree bound loads its JavaScript from `127.0.0.1:8081`. When this worktree's dev server takes port 8081, that app connects to it, and runtime reads read it as this worktree's app (DF22–DF24, root cause DF29). In worktree `mapfilter`, bound to an Android EAS session, `runtime:tree --json` returned `bundle.platform: "ios"`. It read worktree `legend`'s simulator, with old JavaScript. ## Fix A target is another worktree's app when every booted simulator with its device name has a udid that only other worktrees bind with a live lease. When the simulator list cannot be read, a target whose name only other worktrees' bindings hold is skipped. Runtime reads, the debugger client and smoke skip that app, with or without a platform flag, and name the device and the worktree on stderr. `runtime:reload` lists it in `skippedApps` and does not check its platform's bundle. A released or expired binding does not count. smoke names the skipped apps once per run, in its report and on stderr. A runtime read whose list empties after the preflight refuses like the preflight: `NO_APP_CONNECTED`, exit 22. An `--android` run does not ask `simctl` because another worktree holds an iOS lease. The no-app refusals live in `scopeRefusal.ts`, so the debugger client refuses the same way without importing the preflight. Red test: targetSelection-test "skips a target with a foreign binding's name when the simulator list could not be read". Also: e2e runtime-target-selection-test "runtime:eval skips a renamed foreign simulator and names its worktree". Live check: run at the stack top only, not at this layer. The local iOS simulator and EAS session runs (#207, #203) go through this layer's binding lookup, but no app from another worktree was attached, so this layer's claim rests on its red tests. Watch: at this layer, a broadcast reload still reaches the skipped app. #207 stops that. Not in this PR: one `EmptyScopeReason` model for the refusal texts. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

…bound to it (#206) **Every runtime command acts on the device bound to this worktree, and nothing else attached to the same dev server, and says which device it acted on.** This PR makes the device bound to this worktree the scope of every runtime read and of smoke, with or without a platform flag. Stack: #202 → #203 → #204 → #206 → #217 → #218 → #207 → #200 (this is 4/8). ## Problem N2-33: a worktree bound to an iOS EAS session ran `runtime:tree`, which read a local `iPhone 17 Pro` app with the same bundle id and named the session as the device it read. N2-30: on the same kind of worktree, `runtime:tree --ios` refused with "No app connected" while the session's app was connected. ## Fix The scope is this worktree's local binding on the run's platform while its lease is live, else the one live cloud binding, else the flags. A shut-down bound simulator has no app, so a read refuses and names it, and smoke boots it. On Android, the run reads the app whose device name carries the bound serial's model, in the spelling `adb devices -l` uses (`Pixel 9` is `model:Pixel_9`). With two devices of that model, only the one that alone reverses the port is read. An EAS Simulator Android session skips an app on an attached emulator of its model. A wait asks `adb reverse` again for a changed list, so a twin that attaches mid-run cannot authorize a read. One function, `silentTool`, names the device tool that gave no answer, for placement and for the wait's retry. A command with no dev server refuses `NO_DEV_SERVER` before it reads a binding; an unreadable EAS binding refuses `NO_BOUND_DEVICE`. `AGENT_CLI_NO_DEVICE=1` skips only this machine's bindings, so an EAS session still scopes the run. `runtime:reload --json` names the scope under `scope`: platform, how it was chosen, whether it is bound, and the device's backend, id and name. Red tests: targetPlatform-test "matches %s to the attached Android device adb names model:Pixel_9"; e2e runtime-bound-selection-test "eval with android-cloud, flag none, reads androidSession"; targetSelection-test "classifyTargets on a bound phone whose model adb spells differently". Also: e2e "runtime:tree refuses with NO_APP_CONNECTED and does not name the session as read". Live check (adb, on an API 29 emulator whose `Build.MODEL` is `Android SDK built for arm64`): `adb devices -l` printed `model:Android_SDK_built_for_arm64`, and the match accepted the React Native name `Android SDK built for arm64 - 10 - API 29`. `adb reverse --list` printed `host-14 tcp:8197 tcp:8197`; the parser read `tcp:8197` / `tcp:8197`. At the stack top, `runtime:reload --android` read the bound emulator by that model, with an EAS Android app on the same dev server skipped, on 3 of 3 runs. Watch: no physical phone was checked. Not in this PR: one device type for `SelectedDevice` and `NavigateDevice`; one `EmptyScopeReason` model for the refusal texts. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

…217) **Every runtime command acts on the device bound to this worktree, and nothing else attached to the same dev server, and says which device it acted on.** This PR moves the reload broadcast into its own module, so the change in #207 to what a reload reaches reads as a behavior diff. Stack: #202 → #203 → #204 → #206 → #217 → #218 → #207 → #200 (this is 5/8). ## Problem The command-socket rung (the dev server's reload broadcast and the peer-churn wait after it) is inside `src/runtime/reload/reloadAsync.ts`. That file also holds the reload policy, the evidence wait and the relaunch. #207 changes this rung. A move inside the same diff would hide that change. ## Fix A pure move, with no change in behavior. `reloadOverDevServerAsync`, the `CommandSocketChurn` type, `PEER_CHURN_TIMEOUT_MS`, `PEER_POLL_INTERVAL_MS` and the private `waitForPeerChurnAsync` move to the new `src/runtime/reload/rungOne.ts`. The two constants are exported because `reloadAsync.ts` still reads them. `reloadAsync.ts`, `smoke/smokeAsync.ts` and `reloadAsync-test.ts` import them from `rungOne.ts`. The `reloadAsync.ts` code-line cap goes down to 922. Red test: none, because the move changes no behavior. The unit suite passes with only import changes. Live check: run at the stack top only. This layer moves code and changes no behavior. At the top, rung 1 broadcast on a local iOS simulator and was proved by `message-socket-peers` on 3 of 3 reloads. Watch: `reloadAsync.ts` and `rungOne.ts` share the two churn constants until the next split. Not in this PR: the split of `reloadAsync.ts` into evidence, relaunch and report modules. #207 starts it with `evidence.ts`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

…ext (#218) **Every runtime command acts on the device bound to this worktree, and nothing else attached to the same dev server, and says which device it acted on.** This PR gives #207 a proof, per debugger target, that a reload replaced that app's JavaScript context. Stack: #202 → #203 → #204 → #206 → #217 → #218 → #207 → #200 (this is 6/8). ## Problem A `Page.reload` keeps the target's page id, so a fresh target cannot prove it. On main, nothing proves that one target's context was replaced. An acknowledged `Page.reload` does not show that the app reloaded. ## Fix `jsContextReplacedAsync` sets a global with a per-check name, takes the action, and reads the global on the same target id until it is gone. One debugger session owns the marker, the action, the reads and the cleanup. A context that cannot keep the marker is unmarkable, and the action is not taken. An action that the app answers with a CDP error is thrown. An action whose answer is lost may have run, so the marker is read anyway. Each phase has its own bound, and an absolute deadline bounds the whole proof. The open handshake counts against a request's budget, and a request that times out names the whole budget the caller gave. The phase table is in llp/0005 §What proves a reload. Red tests: contextReplaced-test "does not mistake another concurrent check for a replaced context"; "the proof of a Page.reload" rows "reads the marker when the socket drops before Page.reload answers" and "does not prove a reload whose answer was lost and whose context stayed"; cdpClient-test "should name the caller's budget when the socket opened late". Live check: at the stack top, on an SDK 58.0.21 development build on a local iOS 27.0 simulator, with a second app on another simulator so that the run skips one app: `runtime:reload --ios --json` reported `verifiedBy: debugger-context-replaced` (`outcome: context-replaced`) on 4 of 4 reloads, exit 0. On an EAS iOS session (Expo Go, v2 tunnel) with a local simulator app on the same dev server: `runtime:reload --eas` skipped the local app as `other-device` and proved 2 of 2 reloads by `debugger-context-replaced`; `runtime:reload --ios` skipped the cloud app and proved 3 of 3 the same way. On Android at the stack top, with Expo Go on a local API 29 emulator and on an EAS Android session on one dev server: `runtime:reload --android` skipped the cloud app and proved 3 of 3 by `debugger-context-replaced`; `runtime:reload --android --eas` skipped the local app and proved 3 of 3 the same way. Watch: on Android the proof was seen with Expo Go only, not yet with a development build. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

…skips an app (#207) **Every runtime command acts on the device bound to this worktree, and nothing else attached to the same dev server, and says which device it acted on.** This PR makes a reload reach only this worktree's apps when the run skips an app, and prove the reload with this worktree's apps only. Stack: #202 → #203 → #204 → #206 → #217 → #218 → #207 → #200 (this is 7/8). ## Problem The dev server sends its reload broadcast to every app on its port. N2-17: a worktree bound to an iOS EAS session ran `runtime:reload`. It printed "Skipped 1 app on local simulators … iPhone 17 Pro", then "Reloaded yes · via the dev server's client command socket … 2 client(s)". The broadcast also reloaded the skipped app. ## Fix Rung 1 is decided on one target list read after the bundle gate. While the scope skips an app, rung 1 sends no broadcast. It sends CDP `Page.reload` to each own target and proves each with the context marker, under one shared deadline. When nothing is skipped, rung 1 stays the broadcast, and the attempt says when it also reached an app outside the scope. Peer churn beside an app outside the scope makes the attempt `ok: false, delivered: true`: the reload then needs a fresh own target or a bundle. Nothing of an app outside the scope proves the reload. The failure text says whether nothing was watched, the churn was discounted, or the watched observations did not happen. When no own app could keep the marker, it says no `Page.reload` was sent. It names `--eas` and the tunnel only on a cloud run. `Page.reload` has 8 s to prove itself, and the first proof stops the other checks (`stopped`). A `Page.reload` whose answer was lost is not delivered. When the read before rung 1 fails, the run keeps its first placement and sends nothing (mechanism `none`). After a relaunch that nothing can prove, local or cloud, the run exits 22 at once instead of waiting out `--timeout`. CI runs the reload cases that need a local simulator on the macOS job. Red tests: rungOne-test "a broadcast beside an app nothing places: no bundle proves it"; e2e runtime-target-selection-test "sends Page.reload to its own app only, and a page of the skipped app proves nothing ($pageReload)", "sends no Page.reload when its own app cannot keep the marker" and "runtime:reload does not take another platform's churn as its proof". Live check (before the 8 s window and the relaunch exit; not rerun since): at the stack top, on an SDK 58 development build on a local iOS simulator. With a second app on another simulator, the run skipped it as `other-device`, sent `Page.reload` to its own app only, and proved 4 of 4 reloads by `debugger-context-replaced`. With one app, it broadcast and proved 3 of 3 by `message-socket-peers`. On an EAS iOS session (Expo Go, v2 tunnel) with a local simulator app on the same dev server: `runtime:reload --eas` skipped the local app as `other-device` and proved 2 of 2 reloads by `debugger-context-replaced`; `runtime:reload --ios` skipped the cloud app and proved 3 of 3 the same way. Watch: when rung 1 broadcasts, an app that attaches after the last target list also gets the broadcast. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

**Every runtime command acts on the device bound to this worktree, and nothing else attached to the same dev server, and says which device it acted on.** This PR makes `navigate` decide "attached" from the device it opens. Stack: #202 → #203 → #204 → #206 → #217 → #218 → #207 → #200 (this is 8/8). ## Problem `navigate` counted the attached apps of every platform. N3-25 (also DF22): after `dev --android --eas`, with only a local `iPhone 17 Pro` app on port 8081, `navigate "/street/…"` with no flag counted the iOS app as attached. It skipped the launcher, opened only the route link, and exited 22 after 120 s. On Android, the stuck-app recovery could also stop an app that another device ran on the same dev server. ## Fix `navigate` validates the route, resolves the device, and then reads the attached apps of that device's scope to decide the app kind, the route URL and the launcher. One reader serves the launcher wait and the route wait. It reads the device facts again only for a changed list, within the budget of the wait that polls. So a cloud app that attaches after the accepted Expo Go dialog counts. When an Android twin of the bound device is attached, `navigate` reads `adb reverse` before the launcher decision and again after this run's own `adb reverse`. When nothing attached on Android, the recovery stops `--app-id`, else the app config's app, else Expo Go. smoke hands its device to the route open, so the open and the waits are about one device. `--print-url` reads the scope as `navigate` does, `adb reverse` included, once the dev server lists an app. The recovery stops Expo Go when this run opened it, and says the app was stopped only when `pidof` saw it running. The first commit is a pure move of route URL resolution to `src/navigate/routeResolution.ts`. The second commit holds the behavior. Red tests: navigate-target-selection-test "no flag, bound Android emulator, only an iOS app and another model's Android app attached"; navigateAsync-test "asks adb for the device list once while the attach wait polls an unchanged list"; e2e cloud-simulator-test "counts the app that attaches after the dialog is accepted"; navigate-target-selection-test adds three Android twin rows, one of them "no flag, bound Android emulator beside a twin, neither reverses the port before this run". Live check: the `live-cloud` iOS suite passed 17 of 17 at the stack top on an EAS session: `navigate / --eas` exit 0, attached after 3 ms. Plain main gives the same results. Watch: after a wait's budget ends, its later polls keep the last device facts. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

vonovak marked this pull request as ready for review October 24, 2026 03:41

vonovak requested a review from Kudo October 24, 2026 03:41

vonovak marked this pull request as draft October 24, 2026 05:08

vonovak added this pull request to stack #210 October 26, 2026 09:54

vonovak force-pushed the vonovak/fix-cloud-ios-unclaimed-target branch from 74393c1 to 9cc6695 Compare October 26, 2026 17:44

vonovak force-pushed the vonovak/fix-cloud-ios-unclaimed-target branch from 9cc6695 to 187e3d3 Compare October 26, 2026 18:24

vonovak removed this pull request from stack #210 October 27, 2026 17:52

vonovak force-pushed the vonovak/fix-cloud-ios-unclaimed-target branch from 187e3d3 to ffe5054 Compare October 27, 2026 17:53

vonovak added this pull request to stack #212 October 27, 2026 17:53

vonovak changed the title ~~[agent-cli] A runtime read on an EAS Simulator iOS session reads its one unclaimed target (llp/0005 §Android)~~ [agent-cli] An EAS Simulator iOS scope reads its unclaimed target and skips booted local simulators Oct 27, 2026

vonovak mentioned this pull request Oct 27, 2026

[agent-cli] navigate judges attachment on the device it opens #200

Merged

vonovak force-pushed the vonovak/fix-cloud-ios-unclaimed-target branch 2 times, most recently from 12b25cb to 6b2e571 Compare October 27, 2026 21:51

vonovak removed this pull request from stack #212 October 27, 2026 22:47

vonovak added this pull request to stack #219 October 27, 2026 22:47

This was referenced Oct 27, 2026

[agent-cli] Move the command-socket reload rung into its own module #217

Merged

[agent-cli] Prove that a reload replaced one target's JavaScript context #218

Merged

vonovak force-pushed the vonovak/fix-cloud-ios-unclaimed-target branch from 6b2e571 to fdf6912 Compare October 28, 2026 08:48

vonovak force-pushed the vonovak/fix-cloud-ios-unclaimed-target branch from 852a174 to 65ef140 Compare October 29, 2026 03:54

vonovak changed the title ~~[agent-cli] An EAS Simulator iOS scope reads its unclaimed target and skips booted local simulators~~ [agent-cli] An EAS Simulator scope reads its unclaimed target, not apps on local devices Oct 29, 2026

vonovak force-pushed the vonovak/fix-cloud-ios-unclaimed-target branch from 68555ac to 04bcb7f Compare October 29, 2026 18:46

Kudo approved these changes Oct 29, 2026

View reviewed changes

vonovak force-pushed the vonovak/fix-cloud-ios-unclaimed-target branch from 04bcb7f to 2b1aa0a Compare October 29, 2026 19:52

vonovak and others added 14 commits October 30, 2026 10:07

[agent-cli] Quote the other-platform test title exactly in llp/0005

a8f0bfa

The citation carried a stray backslash before the apostrophe, so it named no test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

[agent-cli] Give the no-platform EAS classifier test its own targets

c72bc1d

The test borrowed its describe's `cloud` target and inventory, which a later layer's trim removes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

[agent-cli] Run the booted-simulator EAS reload test on macOS only

198a5cc

A booted local simulator exists only on macOS; on Windows the stub simctl cannot run, so the case tested nothing real there and failed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

[agent-cli] The simctl listing parser returns the valid entries and w…

f82b87d

…hether every entry was valid Each wrapper decides what a bad entry means, instead of a flag that changes the parser's return. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

[agent-cli] The kept-facts wait test builds its scope from the fixture

e5e39f9

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

vonovak force-pushed the vonovak/fix-cloud-ios-unclaimed-target branch from 8820ef5 to 6851f00 Compare October 30, 2026 09:09

[agent-cli] The kept-facts wait tests run as on macOS, where simctl a…

7b7a87e

…nswers On Linux and Windows the iOS facts are unsupported, not unknown, so the tests failed there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

vonovak merged commit 492631a into main Oct 30, 2026
13 checks passed

vonovak deleted the vonovak/fix-cloud-ios-unclaimed-target branch October 30, 2026 10:11

Navigation Menu

Repository navigation

[agent-cli] An EAS Simulator scope reads its unclaimed target, not apps on local devices - #203

[agent-cli] An EAS Simulator scope reads its unclaimed target, not apps on local devices#203
vonovak merged 15 commits into
vonovak/runtime-run-scopefrom
vonovak/fix-cloud-ios-unclaimed-target

vonovak commented Oct 24, 2026 •

edited

Loading

Uh oh!

Kudo Oct 29, 2026

Uh oh!

vonovak Oct 30, 2026

Uh oh!

Kudo Oct 29, 2026

Uh oh!

vonovak Oct 30, 2026 •

edited

Loading

Uh oh!

Kudo Oct 29, 2026

Uh oh!

vonovak Oct 30, 2026

Uh oh!

Kudo Oct 29, 2026

Uh oh!

vonovak Oct 30, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

vonovak commented Oct 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Uh oh!

Kudo Oct 29, 2026

Choose a reason for hiding this comment

Uh oh!

vonovak Oct 30, 2026

Choose a reason for hiding this comment

Uh oh!

Kudo Oct 29, 2026

Choose a reason for hiding this comment

Uh oh!

vonovak Oct 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kudo Oct 29, 2026

Choose a reason for hiding this comment

Uh oh!

vonovak Oct 30, 2026

Choose a reason for hiding this comment

Uh oh!

Kudo Oct 29, 2026

Choose a reason for hiding this comment

Uh oh!

vonovak Oct 30, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

vonovak commented Oct 24, 2026 •

edited

Loading

vonovak Oct 30, 2026 •

edited

Loading