AndroidReality's worst model loses 36.6 points to notifications and permission prompts alone; phoneshell's reflex is built to never auto-answer that exact screen class

Eight Android agents drop 13 to 36 points when AndroidReality injects notifications, permission requests and security sheets into their runs, with UI-TARS-1.5-7B losing 36.61 of its clean 64.20 points to that one perturbation family. phoneshell's own overlay-dismissal code names permission dialogs as the one thing it will never tap on the model's behalf, which means the exact screen class AndroidReality found hardest still reaches the model with no harness help at all, every time.

AndroidReality: How Far Are Mobile Agents from the Real World? (arXiv:2608.07775, Liu, Da, Chen, Ling, Wei, Arizona State University, submitted 7 August 2026) builds a perturbation layer on top of AndroidWorld and organizes it into state, action, and transition perturbations, the last category covering interface interruptions a phone actually produces during normal use: notifications, app update prompts, interstitial ads, permission requests, security verification sheets, and "rate this app" prompts. Across eight open-source agents, including the GUI-Owl and UI-TARS families, success rates fell 13 to 36 absolute percentage points once these were injected. The paper's own description of the effect is not uniform collapse but "high variance," with some agents dismissing the interruption cleanly and others, its words, getting "distracted."

How much a notification or a permission prompt costs, by model

AndroidReality's Table 2 reports clean and perturbed success rates for each model, broken down by perturbation category. The transition category, the one that includes permission requests and notifications, is where the largest single drops show up. UI-TARS-1.5-7B falls from a clean 64.20% (its own paper's reported figure) to 27.27% under transition perturbations, a 36.93-point drop, the worst in the table. GUI-Owl-1.5-32B, the strongest model overall, still loses 25.00 points on the same category, from 72.73% clean to 47.73%. Every model in the table loses more to transition perturbations than to action perturbations, and most lose more than to state perturbations as well.

Source: arXiv:2608.07775, Table 2, success rate (%) on AndroidReality's transition-perturbation subset, read 29 October 2026. UI-TARS clean figures are the models' own reported baselines, per the paper.

phoneshell's own overlay reflex, and the one thing it refuses to do

phoneshell/agent/overlays.py exists to stop a model from burning its step budget narrating its way around a promo sheet or an onboarding screen, a problem its own docstring calls "the single most common way a phone agent stalls." It auto-dismisses sheets, interstitials and paywalls by tapping a close control it finds through a labeled allowlist, CLOSE_LABELS, things like "not now" and "skip." The file states its own boundary in the same docstring: "permission dialogs are NEVER auto-answered, because 'Allow location' is the user's decision, not ours." The code backs that line twice. Its NEVER regex, checked before any tap the reflex considers, blocks on the word allow (and its negation, don't allow) alongside pay, buy, delete and send. And its classify() function gives a system alert its own kind, system_alert, which the step loop explicitly excludes from the auto-dismiss notice it gives the model for every other covering shape: if found is not None and found.kind != "system_alert".

That design choice means permission dialogs, notifications and system alerts, AndroidReality's transition category, reach phoneshell's model with no harness assistance of any kind, neither a dismissal nor even a hint that something is covering the screen. The reflex that handles every other interruption class deliberately sits this one out. The one place phoneshell's own stack does auto-answer a permission prompt is not this path at all: wda/patches.py patches WebDriverAgentRunner itself to call requestAuthorizationForAccessLevel directly against the Photos API when importing media into the camera roll, a one-time grant for the runner's own process, answered through Apple's API rather than a screen tap, and unrelated to any permission dialog a target app shows mid-task.

What it means for a harness that already excludes this screen

• phoneshell's exclusion is deliberate and arguably the safer design: AndroidReality's own text describes agents that mishandle permission prompts getting "distracted," not merely slow, so refusing to auto-tap is a defensible position even at a measured cost in speed or step count.
• The gap is in the second layer, not the reflex. phoneshell/safety.py's Guard.classify_tap, which flags taps needing human confirmation, draws from confirm_patterns, and that list has no entry for "allow," "don't allow," "while using the app," or any other permission-dialog phrasing. If the model itself decides to tap "Allow" rather than the reflex, nothing in the confirmation gate notices. The overlay reflex's restraint and the safety gate's blind spot point at the same screen from opposite directions.
• AndroidReality's own agents are Android models on Android UI; iOS permission sheets differ in exact wording and layout, so the point-drop numbers above do not transfer directly. What transfers is the category: a transition-style interruption phoneshell has not benchmarked against on purpose, because none of its own 80 tasks currently inject one.

Check it yourself

# phoneshell's own stated boundary on permission dialogs
sed -n '1,13p' phoneshell/agent/overlays.py

# the NEVER regex that blocks "allow" from the auto-dismiss reflex
grep -n "^NEVER" -A3 phoneshell/agent/overlays.py

# system_alert excluded from the auto-dismiss notice given to the model
grep -n "system_alert" phoneshell/actions.py phoneshell/agent/overlays.py

# confirm_patterns has no permission-dialog entry
grep -n "confirm_patterns" -A10 phoneshell/config.py

# AndroidReality's own transition-perturbation table
curl -s https://arxiv.org/html/2608.07775v1 | grep -iE "Table 2|transition|permission"

What would prove this wrong

We claim phoneshell's auto-dismiss reflex never fires on a system alert, including permission dialogs, and that its separate tap-confirmation gate has no pattern matching "allow" or similar permission-grant language. Both claims are falsified by the greps above returning a different result than shown, and we encourage running them directly. We also claim this matters because AndroidReality measured the largest, most variable success-rate drops in exactly this screen category, 13 to 37 points, across eight Android agents; that transfers as a category, not as a number, since phoneshell has never run its own 80 tasks against an injected permission prompt or notification. We will treat either a repository change to this exclusion, or a phoneshell run against an injected interruption of this kind, as grounds to revisit this piece by 30 April 2027.