Qwen-UI-Agent runs bash commands from its GUI action space on 100+ real phones; phoneshell has never issued a shell command to one

One action in Qwen-UI-Agent's tool set drops straight to a bash shell. phoneshell's entire action module, read line by line, never leaves the accessibility tree and the touchscreen. The gap is not capability, it is scope: one project is a foundation agent for four environments, the other is a grading harness for one phone.

Qwen-UI-Agent's technical report, submitted to arXiv on 30 July 2026 by Hanzhang Zhou and 15 co-authors, gives its agent a cli_command action, described in the paper as enabling "direct bash command execution" from the same unified action space as its GUI taps and batched actions. That action space trains across what the report calls "a real-device mobile environment comprising over 100 physical devices" plus "up to 10,000 isolated sandbox environments running in parallel," on trajectories the authors say exceed 100 interaction steps under online reinforcement learning. phoneshell's own action module, phoneshell/actions.py, defines roughly thirty methods an agent can call, every one of them a WDA call: tap_element, type_text, swipe, press_key, open_app, open_url, and so on. None of them opens a shell, because phoneshell drives exactly one device and was built to measure what a model can do through the screen alone.

One action space, two execution surfaces

The report's own framing is that Qwen-UI-Agent is "a foundation GUI agent for mobile, computer-use, web, and DeepSearch environments," and the unified action space is what lets one model move between them: GUI operations for tapping and typing, cli_command for anything better expressed as a shell call, and batched actions for issuing several steps at once. The paper gives no example syntax for cli_command beyond naming it, but it is explicit that the action executes in "the active CLI environment," meaning the model can choose, mid-task, whether the next step is a tap or a command. Training that action space at scale needed two kinds of rollout capacity: sandboxes, up to 10,000 running in parallel, with virtual screens the authors say increase throughput "approximately 20x" relative to the same cluster without them, and the real-device runtime itself, over 100 physical phones used for "trajectory collection, online reinforcement learning, and evaluation on real devices," with a VLM-based judge checking each completed trajectory before validated ones are kept for training. Online RL was then scaled to trajectories the report says exceed 100 interaction steps, an order of magnitude past what a single phoneshell task is allowed to take.

Nothing in phoneshell's actions.py has a shell-adjacent equivalent. The closest thing to a non-GUI action in the whole module is open_url, which opens a deeplink through the existing GUI session rather than executing anything outside it; runner.py does call subprocess.run, but only to launch the Claude Code CLI harness itself, not as an action the agent under test can choose to invoke. Every one of the roughly thirty callable methods in actions.py, from tap_point to scroll_to_text to set_picker, bottoms out in a WebDriverAgent call against the one iPhone phoneshell has open. There is no step in any phoneshell task where the model can decide to do anything other than touch the glass.

The scores it reports, and the one we can check independently

Qwen-UI-Agent's abstract reports seven benchmark figures: 82.1% on MobileWorld, 92.2% on MobileWorld-Real, 97.5% on AndroidDaily, 79.5% on OSWorld-Verified, 40.0% partial progress on OSWorld-v2, 73.6% on WebArena, and 81.5% on ScreenSpot-Pro. Of those seven, AndroidDaily is the one this site has already independently sourced: AndroidDaily (arXiv:2605.27761) is a verifiable benchmark for mobile GUI agents on real-world closed-source applications, released 26 May 2026, and already carries a grade-A entry in the Blomega registry. That does not independently confirm Qwen-UI-Agent's 97.5% score on it, which still rests on the report's own self-reported number, but it does confirm AndroidDaily itself is a real, checkable benchmark rather than an invented one, which is more than can be said for several figures in papers this site has had to discount in past entries.

What it means for anyone sizing up a gap

• Adding a shell-executing action is a scope decision, not a difficulty upgrade. phoneshell's lack of one is not a gap it failed to close; its entire purpose is to measure what a model can do through the screen a person actually sees, and a cli_command action would let a model route around that screen entirely, which would stop measuring the thing phoneshell is for.
• The 100+ device fleet and 10,000-sandbox training capacity exist to generate enough rollouts to move a 16-author, multi-environment foundation model's weights. phoneshell's one device exists to generate a trustworthy score for whichever already-trained model a user points at it. The device-count gap is a direct consequence of that purpose gap, not evidence that phoneshell's methodology is thin.
• Trajectories "exceeding 100 interaction steps" under online RL are a training-time property; nothing says Qwen-UI-Agent's deployed inference calls run anywhere near that long. phoneshell's own 60-step hard cap is an evaluation-time property, bounding how long a model gets to finish one of its 80 tasks. The two numbers answer different questions and should not be read as "phoneshell gives models 40% less room."
• Only one of the seven reported scores, AndroidDaily, lands on a benchmark this site has independently sourced as real. The other six, MobileWorld, MobileWorld-Real, OSWorld-Verified, OSWorld-v2, WebArena and ScreenSpot-Pro, are all established benchmarks elsewhere in the literature, but Qwen-UI-Agent's specific scores on them are, as far as this check went, self-reported figures from the paper's own abstract.

Check it yourself

# every action phoneshell exposes to an agent, and confirm none executes a shell
grep -nE "^    def [a-z_]+\(" phoneshell/actions.py
grep -rliE "subprocess|os\.system|shell=True" phoneshell/actions.py || echo "no shell execution in actions.py"
grep -n "subprocess.run" phoneshell/bench/runner.py   # infra only, not an agent-callable action

# phoneshell's hard step cap, for comparison against Qwen-UI-Agent's >100-turn RL trajectories
grep -n "max_steps" phoneshell/config.py phoneshell/bench/schema.py

# Qwen-UI-Agent's own numbers
curl -s https://arxiv.org/abs/2607.28227 | grep -i "cli_command\|physical devices\|interaction steps"
# full report with examples: https://arxiv.org/html/2607.28227

What would prove this wrong

We claim phoneshell's action module has no action that executes outside the GUI, specifically nothing that opens a shell or runs an arbitrary command. That is wrong if any method added to phoneshell/actions.py wraps subprocess, os.system, or an equivalent, and is exposed as a callable action rather than internal plumbing. We also report Qwen-UI-Agent's seven benchmark scores as self-reported from its own abstract; that framing is wrong, in Qwen-UI-Agent's favor, if an independent third party reproduces those scores on the cited benchmarks and publishes matching numbers. We will check both, phoneshell's own commit history and any independent reproduction of Qwen-UI-Agent's results, by 30 April 2027.

Sources

• Zhou, Tong, Zhang, Kong, Cai, Xia, Zhang, Zhang, Li, Chen, Wang, Dai, Li, Chen, Wang, Hoi, Qwen-UI-Agent Technical Report: Toward Next-Generation Real-World Centric Foundation GUI Agents, arXiv:2607.28227, submitted 30 July 2026, read 15 October 2026.
• Full text: arxiv.org/html/2607.28227.
• AndroidDaily benchmark, arXiv:2605.27761, released 26 May 2026, independently graded in the Blomega registry: arxiv.org/abs/2605.27761.
• Blolabel, phoneshell: phoneshell/actions.py, phoneshell/config.py, phoneshell/bench/schema.py, phoneshell/bench/runner.py, read 15 October 2026.