The pointer was still on its way

2026-10-23

An agent chose the right button and then appeared to wait for almost a minute. The page eventually changed, so the operation looked successful in its final receipt. In a long workflow, those successful minutes made the queue crawl.

Our first suspicion was that two layers were both drawing a human pointer trajectory. The trace did not support it. The page received one curved approach, but many consecutive movement events arrived about a second apart. Other clicks on the same runtime were fast. Matching the page events to the command windows put most of the delay before the button press, rather than in the final context save. It located the slow phase without explaining the underlying runtime cause.

The approach was still trying to deliver every intermediate point after it had fallen behind. For a click, the destination matters more than faithfully replaying an old travel schedule. We kept the curve and gave each planned point a small allowance for dispatch and pauses. Once a point is stale, the click approach may skip it. The final coordinate is always awaited, including the existing overshoot correction, before a button goes down. Ordinary moves and hover retain their complete paths, since intermediate positions can be the point of those actions.

The small change needed more than a faster stopwatch. In a fresh native browser, a local page counted trusted pointer events and changed its address after one click. With an explicit one-second delay added after each mouse acknowledgement, the old approach took 51.18 seconds and sent 50 moves; the new one took 5.36 seconds and sent five. Both reached the exact target, pressed once and completed the fragment transition. Without that injected delay, both took about 1.15 seconds and sent 50 moves. Failure and cancellation tests also checked that an unfinished approach could not press the button.

That experiment supports a mitigation, not a diagnosis of the production browser. The isolated browser's actual acknowledgements were fast. A sparse path is also a real tradeoff, including at ordinary latency, and one blocked browser call can still wait. In this delayed-dispatch fixture, skipping stale waypoints avoided replaying most of that minute. The investigation into the production cadence remains open.

We also put the installed candidate through the current O Chat production build. A real model requested two one-time tool approvals, clicked the static fixture once and sent its screenshot through native Host image IO. The phone reload check initially accepted cached completion text too soon; independent review caught the still-reconnecting state. The corrected test now waits for a new connection, the Send control and the same loaded image, while checking that neither input nor click was replayed. The scoped consumer acceptance records the exact coverage and the remaining production boundary.

Getting the faster path into a working service exposed a second kind of wait. The existing browser belonged to more than one task. Restarting it to load a small input fix would have stopped someone else's work, so the reimbursement worker needed a separately owned runtime. A healthy preflight was not enough: the next CLI command could quietly start a replacement if that daemon died. The supervisor's no-restart policy did not govern the client's startup path.

An optional daemon PID pin gives the managed worker a different contract from an interactive terminal. Missing or changed ownership becomes a visible error, including after an engine probe, rather than a request to create another browser. Independent review followed the same boundary through close, where force cleanup must not adopt a replacement process. A real CLI trial exercised that boundary without opening a page or a paid session. The ordinary unpinned CLI still starts a browser on demand.

The candidate packages both changes, but they have separate evidence. A bounded gesture demonstrates less accumulated dispatch delay. A daemon pin identifies which process the worker may use or clean up. Neither result proves the remaining business queue is complete, or that copying a version number into a running service has upgraded its live browser. That last step still needs a published artifact, fresh runtime checks and an actual bounded business trial.