Summary
After asynchronous request-help interruptions, the in-page overlay <browser-skill-overlay> (the "Agent 正在控制" badge + 「中断」 button) can enter a stuck state in which it permanently covers the whole viewport with pointer-events: auto. While stuck:
bsk click reports success but the page never receives the click (verified via document.activeElement).bsk upload --mode drop fails with permission_denied: "file-drop target is not the topmost element at its action point".bsk upload (input mode) fails with "upload trigger did not activate an input[type=file]".
Removing the DOM node or reloading the page does not help; new sessions/windows also get the stuck overlay. Only reloading the extension clears it.
Environment
- bsk CLI + daemon: 0.3.0 (protocol 1.3), daemon running natively on Windows 11 x64, ws on 127.0.0.1:52800 (local mode)
- Extension: 0.3.0, in Microsoft Edge 153.0.0.0 (Windows)
- Page where observed:
https://member.bilibili.com/platform/upload/video/frame (the symptoms look page-independent)
Trigger (observed twice in one day)
- A
bsk request-help client process was killed by a client-side timeout (shell timeout → SIGTERM). Afterwards the session stayed busy: "previous session command is still running / session already has an unfinished command".
- Another
bsk request-help ended with: error: timed out waiting for human confirmation / details: request-help timed out and cleanup could not be confirmed.
After these, the overlay stayed permanently active with no agent operation in flight.
Evidence (collected via bsk evaluate while stuck)
document.querySelectorAll('browser-skill-overlay').length // 1
// host covers the full viewport (e.g. 1189x618), computed style:
// pointer-events: auto, z-index: 2147483647, display: block
document.elementsFromPoint(624, 340)
// -> ["BROWSER-SKILL-OVERLAY.", "DIV.upload-area", "DIV.bcc-upload-wrapper", ...]
// the overlay is topmost at every probed pointClick test: bsk click --selector 'input[placeholder*="回车"]' → click ok ... at=(711.4, 301.5), but right after, document.activeElement is still <body> — the click never reaches the page.
Upload failure (drop):
{"code":"permission_denied",
"message":"file-drop target is not the topmost element at its action point",
"data":{"mechanism":"drop","phase":"resolve_target","reason":"file_drop_target_unavailable"}}Removing the overlay node via bsk evaluate (h.remove()) works momentarily (count: 0), but it is re-injected (count returns to 1), so no client-side workaround persists.
Secondary issue: persistent "user interrupt" state
Activating the overlay's 「中断」 button (.click() inside its shadow root) puts the extension into a pending-interrupt state where every subsequent tool dispatch is rejected:
error: operation interrupted by user
details: tool dispatch rejected: pending user interrupt. The user explicitly requested to stop. Ask the user how to proceed before issuing further actions.
This state also persisted until the extension was reloaded (no way to resume otherwise).
Impact
While stuck, no pointer-based bsk operation can succeed in the affected window(s) — clicks and uploads are unusable — until the user manually reloads the extension.
Workarounds / recovery
- Recovery: reload the extension (
edge://extensions → Reload). Clears both the stuck overlay and the pending-interrupt state.
- Do not kill the
request-help client mid-flight and give it a generous timeout — the resulting "cleanup could not be confirmed" states seem to precede the stuck overlay.
- While stuck,
bsk evaluate still works; interactions can be bridged from JS (element.click(), synthetic DataTransfer drop with files), which is how we completed the task.
Possibly related observation
If the Agent Window is placed off-screen or fully covered by other windows, pages report document.visibilityState === "hidden" and drag/measurement-based operations fail (No node found at given location in drop resolve_target; scroll-to → visibility measurement timed out). Restoring the window on-screen and focused fixes those. It may be worth checking whether overlay lifecycle and window-visibility handling share the same root cause.
Summary
After asynchronous
request-helpinterruptions, the in-page overlay<browser-skill-overlay>(the "Agent 正在控制" badge + 「中断」 button) can enter a stuck state in which it permanently covers the whole viewport withpointer-events: auto. While stuck:bsk clickreports success but the page never receives the click (verified viadocument.activeElement).bsk upload --mode dropfails withpermission_denied: "file-drop target is not the topmost element at its action point".bsk upload(input mode) fails with"upload trigger did not activate an input[type=file]".Removing the DOM node or reloading the page does not help; new sessions/windows also get the stuck overlay. Only reloading the extension clears it.
Environment
https://member.bilibili.com/platform/upload/video/frame(the symptoms look page-independent)Trigger (observed twice in one day)
bsk request-helpclient process was killed by a client-side timeout (shelltimeout→ SIGTERM). Afterwards the session stayed busy:"previous session command is still running / session already has an unfinished command".bsk request-helpended with:error: timed out waiting for human confirmation/details: request-help timed out and cleanup could not be confirmed.After these, the overlay stayed permanently active with no agent operation in flight.
Evidence (collected via
bsk evaluatewhile stuck)Click test:
bsk click --selector 'input[placeholder*="回车"]'→click ok ... at=(711.4, 301.5), but right after,document.activeElementis still<body>— the click never reaches the page.Upload failure (drop):
{"code":"permission_denied", "message":"file-drop target is not the topmost element at its action point", "data":{"mechanism":"drop","phase":"resolve_target","reason":"file_drop_target_unavailable"}}Removing the overlay node via
bsk evaluate(h.remove()) works momentarily (count: 0), but it is re-injected (count returns to 1), so no client-side workaround persists.Secondary issue: persistent "user interrupt" state
Activating the overlay's 「中断」 button (
.click()inside its shadow root) puts the extension into a pending-interrupt state where every subsequent tool dispatch is rejected:This state also persisted until the extension was reloaded (no way to resume otherwise).
Impact
While stuck, no pointer-based
bskoperation can succeed in the affected window(s) — clicks and uploads are unusable — until the user manually reloads the extension.Workarounds / recovery
edge://extensions→ Reload). Clears both the stuck overlay and the pending-interrupt state.request-helpclient mid-flight and give it a generous timeout — the resulting "cleanup could not be confirmed" states seem to precede the stuck overlay.bsk evaluatestill works; interactions can be bridged from JS (element.click(), syntheticDataTransferdrop with files), which is how we completed the task.Possibly related observation
If the Agent Window is placed off-screen or fully covered by other windows, pages report
document.visibilityState === "hidden"and drag/measurement-based operations fail (No node found at given locationin dropresolve_target;scroll-to→visibility measurement timed out). Restoring the window on-screen and focused fixes those. It may be worth checking whether overlay lifecycle and window-visibility handling share the same root cause.