feat(browser): batch planned page actions and keep snapshot ids after refused clicks - #8214
Conversation
…used An observed click refused before dispatch (for example, covered by an overlay) never starts its observation, yet it invalidated every id in the snapshot, so the agent could not click the overlay's own close button without re-observing. A failed observed action with no dispatched outcome now only cancels an in-flight capture, which clears the refs itself when it starts.
The desktop runs 2-8 single-page interactions from one authorized call, in order, stopping at the first failed action or after an action navigates, switches tabs, or invalidates the snapshot's element ids. A batch stopped by a failure reports an error status; one stopped by a page change does not. Once an action has run, a cancelled or timed-out batch reports an unknown outcome so the agent does not repeat it.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
|
There was a problem hiding this comment.
4 issues found across 10 files
Confidence score: 2/5
apps/desktop/src/main/browser-agent/post-action-observation.tsandapps/desktop/src/main/browser-agent/driver.tscan report a batch as an ordinary error or cancellation after its first nested action has already dispatched, which may cause the model to repeat input or other side effects; mark the first action pending as soon as dispatch begins and preserve the partial-outcome state.apps/desktop/src/main/browser-agent/driver.tsdoes not detect same-document SPA navigation viapushState, so later batch actions can run against a changed page and produce incorrect or unsafe results; include URL/history-based navigation detection before continuing the batch.packages/browser-protocol/src/index.tsexposesbrowser_batchto older supported shells whose IPC allowlists reject the tool, causing compatibility failures; gate the tool by shell support or raiseMIN_DESKTOP_VERSION.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="apps/desktop/src/main/browser-agent/post-action-observation.ts">
<violation number="1" location="apps/desktop/src/main/browser-agent/post-action-observation.ts:13">
P1: An observed batch can be reported as an ordinary error after its first action has dispatched but hangs, inviting the model to repeat it. Mark the first nested action pending once dispatch begins so cancellation reports an unknown outcome.</violation>
</file>
<file name="packages/browser-protocol/src/index.ts">
<violation number="1" location="packages/browser-protocol/src/index.ts:46">
P2: Adding `browser_batch` exposes it to older supported shells, whose unchanged IPC allowlist rejects it as an unknown tool. Gate the tool by shell support or raise `MIN_DESKTOP_VERSION`.</violation>
</file>
<file name="apps/desktop/src/main/browser-agent/driver.ts">
<violation number="1" location="apps/desktop/src/main/browser-agent/driver.ts:3461">
P1: The first action can dispatch input before it returns, but the batch does not mark its outcome pending until action 1. Cancellation after that first dispatch therefore returns an ordinary cancellation instead of `outcomeUnknown`/`doNotRetry`, allowing the agent to repeat an action that may already have run; report pending as soon as the first action can dispatch.</violation>
<violation number="2" location="apps/desktop/src/main/browser-agent/driver.ts:3485">
P1: This check misses same-document SPA navigation: `navigationEpoch` changes only for cross-document loads, so a click that changes the URL with `pushState` can leave it unchanged and the batch will run later actions against stale page state. Also stop when the action reports a URL change or when the tab URL differs from its pre-action URL.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
|
…ocument URL changes A batch now reports its outcome as pending before every action, since an action can dispatch input before it returns; a cancelled or timed-out batch therefore never reads as not started. It also stops after an action changes the tab URL within the document, not only on cross-document navigation.
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
Summary
browser_batch: the desktop runs 2–8 single-page interactions from one authorized call, in order, stopping at the first failure or after an action navigates, switches tabs, or invalidates snapshot ids. A batch stopped by a failure reports an error status; once an action has run, a cancelled or timed-out batch reports an unknown outcome so it isn't repeatedCompanion: simstudioai/mothership#515
Type of Change
Testing
Paired A/B on the production browser model (gemini-3.8-flash), staging vs this branch plus the mothership side:
Desktop 1,878 tests, Sim browser client 1,160 tests, type-check, lint, and all 49 audits pass. New tests were checked to fail without their fix.
Checklist