[Windows/DSH] Anti-debugging pages are unusable: observe fails with "observation document identity changed", plus other setup pitfalls #465

Environment

• DSH: 0.2.1-rc.2
• DSH plugin @wxg-prc-cpg/browser-skill-dsh-plugin 0.3.3, bsk 0.3.3 (daemon 0.3.3, protocol 1.3), extension 0.3.3
• Windows, Microsoft Edge 155.0.0.0 (instance 2f3a8a99), DSH with browser tools; approval prompts disabled

Overlap with existing issues — what is new here

I searched the tracker after filing this. Several sections overlap existing issues; the pointers below say what each one adds, so this report can be judged on its increment rather than re-read as a duplicate.

• Section 1 — #454 already traces the anti-debugging root cause on the same site (a console-consumer timing heuristic; Runtime/Log domains enabled on every attach) and asks for a quieter attach mode. Section 1 is the same root cause seen from the consuming side; what is added here is that every operation loops, including read-only ones, and that the ask is a non-debugging control path plus fast detection and fallback instead of a retry loop.
• Section 4 — #392 covers the same breakaway failure and the misleading diagnostic, #337 the autostart/launcher request and the undocumented idle exit, #218 and #268 the daemon dying with the launching process. Section 4 adds: the plugin should own/supervise the daemon, and the host-visible symptom that browser tools stay broken until it is restarted by hand.
• Section 7 (idle bullet only) — #386 reports the same silent mid-use loss, and #456 the 5-minute default. That bullet is that report; what section 7 adds is the control-by-control comparison (中断 / closing the Agent Window / Edge's infobar / idle) with measured outcomes.
• I found no existing issue for section 2 (no concurrent / co-driving control — nearest items [Feature Request] 多任务并发时增加冲突预检（session 混用 / 同域登录态冲突检测） #132 and Stuck 'Agent is controlling' overlay blocks all real clicks and makes bsk upload fail (extension reload required) #277, neither the same thing), section 3 (the CLI is not installed with the plugin), section 5 (extension-connection diagnostics) or section 6 (the borrow hint only existing in a reference doc).

1. Pages with anti-debugging / anti-automation protection are effectively unusable (main issue)

On a job-board search page that ships anti-debugging protection:

• bsk_inspect observe failed three times in a row with:

  bsk observe failed: observation document identity changed or could not be verified; observe again
  (hint: confirm the tab is still in a loaded state and retry; reloading the tab usually resets a stuck DevTools session)
  

• The page reloads itself as soon as the debugger is attached (site-side anti-debug detection; root cause traced in [Feature] Quieter attach mode for pages with console-consumer anti-debugging (skip Runtime/Log domains) #454). The user saw the tab "refreshing continuously": every observe retry attaches again and causes another self-reload. Following the hint and calling reload makes it worse on such sites.

• screenshot still works, but no data ever arrives: the result list stays on skeletons (grey placeholders) for an automated session, so the page cannot be read even visually.

• The session then died: bsk navigate failed: session not registered or already stopped. The CLI (bsk session list) reported no active sessions, while the DSH plugin still listed the session as [current]. The daemon log shows why: session removed: user closed Agent Window — closing the Agent Window removes the session outright. (The other session in this report was lost the same way by idle session stopped; see section 7.) Neither the Agent Window's 中断 button nor Edge's «"BrowserSkill"已开始调试此浏览器» infobar ends the session — both verified.

Requests:

• Provide a non-debugging way for an agent to drive the browser — a tool/CLI path that operates the page without attaching a debugger, since attaching one is exactly what these sites detect. Without it, such pages cannot be automated at all. (Related: [Feature] Quieter attach mode for pages with console-consumer anti-debugging (skip Runtime/Log domains) #454 asks for the narrower "quieter attach" version of this.)
• Make that path actually usable and efficient: fast enough to call in a loop, reliable at returning the page's real content, and adequate for ordinary tasks (read a list, fill a form). "Can be used" matters more here than feature breadth.
• Detect the anti-debugging / anti-automation condition quickly and name it clearly: fail fast with a distinct error (e.g. "this page rejects automated/debugged control") instead of the observation document identity changed churn loop, so the agent knows to switch to another approach (or hand back to the user) instead of retrying. Do not suggest a plain reload in that case.

2. No concurrent control: the user and the agent cannot work on the same page at the same time

• While the agent holds a session, the user cannot type into fields or click buttons on that tab. Taking over means pressing the Agent Window's 中断 (interrupt) button. That hand-off works and is lossless: after the user pressed it, the session stayed alive, the tab stayed on the same page, and the entire unsent draft (title plus a ~5.9K-character description) was still there when the agent re-attached.
• What is missing is any concurrent / co-driving control. You cannot split work on a single page — for example, the agent fills one part of a form while the user fills another part at the same time; a reviewer cannot type corrections while the agent keeps editing; and nothing in the page shows who currently holds control. Control is strictly exclusive and has to be handed over by hand, one side at a time. (Nearest existing items: [Feature Request] 多任务并发时增加冲突预检（session 混用 / 同域登录态冲突检测） #132 asks for conflict pre-checks between sessions, Stuck 'Agent is controlling' overlay blocks all real clicks and makes bsk upload fail (extension reload required) #277 reports the “Agent is controlling” overlay blocking clicks — neither provides shared control.)
• Related nit: immediately after the interrupt, the next tool call was rejected with tool dispatch rejected: pending user interrupt. The user explicitly requested to stop. Ask the user how to proceed before issuing further actions. — yet an immediate retry, with no additional confirmation from the user, went through. The gate behaves as one-shot rather than "ask the user first".
• Requests: support a shared/co-driving mode (or at least document a "release for human input → agent re-attaches" flow, which already preserves state) plus a visible indicator of who currently holds control; and document that the 中断 button is the hand-off mechanism, which is not obvious today.

3. The bsk CLI is not installed together with the DSH plugin

After installing the DSH plugin, the first browser tool call failed with:

the bsk CLI ("bsk") was not found. BrowserSkill must be installed and on PATH for browser tools to
work — install it from https://github.com/Tencent/BrowserSkill (see the README install script or
`cargo install`), then retry.

I had to run irm https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.ps1 | iex manually. The plugin already has a bskPath option (default "bsk" in lib/index.mjs); offering to install the CLI, or pointing the error at that option, would help.

4. Windows: the daemon cannot auto-start detached (Job Object), and the defaults reap it

bsk doctor reported:

FAIL daemon running  automatic daemon startup failed: cannot start an independent Windows daemon;
the host may prohibit Job Object breakaway; use `bsk daemon start --foreground` in a persistent host
task or start from an independent terminal: 拒绝访问。 (os error 5)

Workaround: run bsk daemon start --foreground as a persistent host task and set BSK_AUTO_START=0 for client commands. Same failure and diagnosis: #392 (Windows 11 nested jobs make this error misleading); autostart/launcher request: #337; daemon dying with the launching process: #218, #268.

Worth noting for the same section: --daemon-idle defaults to 10 minutes and --session-idle to 5 (also raised in #337, #456), so a host-managed daemon that looks like it "keeps dying" may simply be reaping itself while idle. Letting the plugin own/supervise the daemon as a child process on Windows (with explicit, documented timeouts) would remove this whole class of failures.

5. Extension-connection diagnostics are ambiguous

Right after installing the Edge extension, bsk doctor showed:

FAIL extension connected  0 browsers connected — hint: install the extension from
https://chromewebstore.google.com/... or https://microsoftedge.microsoft.com/...

even though the extension was installed (multiple Edge profiles, "local connection" toggle, or a daemon on another port are all equally plausible). Later runs printed waiting for browser extension to connect…. A hint that distinguishes "not installed" from "installed but not connected (wrong profile / local connection off / different daemon or port)" would save a lot of guessing. (Related: #265 — doctor can hang before that hint is ever printed; #202 and #395 — extension not reconnecting to the daemon.)

6. Borrowing an unowned tab

An unowned tab inside the Agent Window needs a user move to a user window before borrowing. This only appears in a reference document, not in the tool error or the short docs, so it costs a round trip when the target tab happens to live in the Agent Window. (Related: #116, #279.)

7. The controls that end a session are ambiguous, and one of them silently closes the page the agent opened

Four different user-facing controls can affect a session, and nothing in the UI says what each one does to the page the agent opened (~/.bsk/daemon.log.2026-10-18, timestamps UTC):

• Agent Window 中断 button → user-interrupt: cancelled inflight tools, "session":"wdyv","count":0. Verified safe: the session survives, the tab stays, the unsent draft survives.
• Closing the Agent Window → session removed: user closed Agent Window, "session":"vokb". The session is removed outright, and the tab the agent opened goes with it.
• Edge's own infobar «"BrowserSkill"已开始调试此浏览器 [取消]» → verified harmless: after the user pressed 取消 the session was still registered, observe still returned live refs for the page, the title and the whole 8.7K-character body were still in the form, and the daemon log recorded no session event at all (only the viewport height changed, 868 → 870, i.e. the infobar itself was dismissed). The problem is that nothing — not the log, not the UI — says that in advance, so neither the user nor the model can predict whether this button ends the session or closes the tab.
• Idle timeout → idle session stopped, "session":"wdyv", at 12:55:46Z. Default is 5 minutes (bsk daemon start --session-idle, default 5m; --daemon-idle, default 10m). This ended the session while we were reviewing the very issue draft this report is written in, and the tab the agent had opened was then gone from the browser, taking the unsent issue text with it. GitHub did not restore the draft on a fresh /issues/new load; only a local copy saved it. (Same silent loss reported in [Bug] A session is reclaimed mid-use and the borrowed tab's page state is lost, with no warning #386; same default in browser session idle time too short. 5 minutes ? Make it longer or user configurable #456.)

So the same "make it stop" gesture has four different, undocumented outcomes, and neither the user nor the model can predict whether a given control will (a) cancel the current action, (b) end the session, or (c) close the tab the agent opened and discard in-page state.

Requests:

• State next to each control what it does ("stop the current action" vs "stop the session" vs "close the tab the agent opened"), and give the destructive one different wording and a confirmation.
• Do not silently close a tab the agent opened when a session ends — detach instead, or ask first; at minimum keep the tab so in-page state stays recoverable.
• Surface idle stops: when a session ends because of the idle timeout, say so (in the UI, and to the agent as a distinct error instead of only session not registered or already stopped) and say how to raise the timeout.
• Document, for each of these paths, whether unsent in-page state survives.