You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] After a cdp_extension_access_denied failure and re-navigate, evaluate runs in a different tab of the same browser with no error #420
After a background session's tab hit a cdp_failed / cdp_extension_access_denied error and the agent re-navigated it, a later evaluate in the same session ran against a different page: an unrelated web app in another tab of the same browser, not the page the session had navigated to. Nothing in the result showed that the target had changed, so a script written for one page ran in another. For agents that run in-page scripts, including ones that fill forms or read values, this is a safety hazard.
Environment
BrowserSkill CLI bsk driving an Aside/Chromium browser on macOS through the extension.
A background session (session start --no-focus), with the user active in other tabs at the same time.
Sequence (sanitized)
bsk session start --json --no-focus gave session S.
bsk navigate https://<sign-in page>/ --session S, then observe: the expected form, with refs for an email textbox and a submit button.
bsk fill @eN <email> --session S and bsk click @eM --session S: both returned ok.
bsk navigate https://<sign-in page>/ --session S returned ok, and observe showed the sign-in form again.
bsk evaluate "<script reading document.querySelectorAll('input')>" --session S returned the inputs of a different app: a chat app's search box, plus a range input and a file input. The sign-in page's email input was absent.
So between steps 5 and 6, evaluate ran in a different document from the one observe had just reported, with no error and no tab id in the result telling the caller.
Expected
evaluate, click and fill in a session always target the session's own tab, the one its last navigate or observe reported. If that tab is gone or unreachable, the command fails with an explicit error and never falls through to another tab.
Every result carries the tab_id and URL it actually ran against, so a caller can check the target cheaply.
Actual
evaluate silently ran in a different, user-owned tab.
Workaround we use meanwhile
Before every scripted evaluate or click, re-read the tab's URL and title and stop on any mismatch.
Activity