RobotyA scrolling gesture coincided with four simulation launches
An assisted iPhone walkthrough produced four unintended starts. The uncertain trigger matters, but so does the distinction between a successful run and a deliberate one.
Covers September 23, 2026. Reconstructed later from available records.
During a September 23 iPhone walkthrough, scrolling with our UI automation helper coincided with four launches of a local simulated Reach task.
The intended action was to inspect the workspace. The required review and approval to start simulations had not happened. Each launch nevertheless created a distinct operation and completed successfully.
These were baseline simulations, with no model inference or physical robot. A successful result did not make their starts intended or authorized.
The cause remains uncertain
The helper's direct-tap allowlist excluded Start. Scrolling used a separate generic swipe across a workspace with a fixed Start button. The logs do not establish which touch dispatched the launches.
That is enough to identify a gap without inventing its cause. Restricting direct tap commands did not constrain every gesture that could reach an action. Nor was that helper restriction an application-level authorization check.
Starting needs its own design
We changed the helper to reject scrolling whenever Start was visible and added an explicit confirmation to Start simulation. Nineteen helper tests passed. The next device build succeeded and was installed, but was not launched. At that checkpoint, the new guard had not been observed in a device walkthrough.
The separate Stop investigation asks what proves an active task has ended. Here the question comes earlier: what makes its beginning deliberate?
Retaining the revision, operation and run context let us distinguish four starts from one repeated display. That evidence also prevented the success messages from hiding the more important outcome: the walkthrough had caused work it was not supposed to start.