diff options
| author | Uttkarsh <38376852+uttkarsh-26@users.noreply.github.com> | 2026-10-12 00:09:18 +0530 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2026-10-12 00:09:18 +0530 |
| commit | 2601c90bc0ec54f1e6234d05112c99c458d4ae5e (patch) | |
| tree | da4a590aacf80fe87308d63b33bd2d6abdfc28e9 /skills | |
| parent | 014de0ec21936a7a2fd64db9d151e73c79bb44ad (diff) | |
fix: browser_download no longer hijacks the user's own downloads (#33)
Browser.setDownloadBehavior was sent without a browserContextId, so the override applied to the
user's default context and outlived the session. browser_download now takes restore:true, tracks
the override this process set, and a clean session shutdown restores Chrome's default with a
bounded call that is skipped when the browser is already gone.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Diffstat (limited to 'skills')
| -rw-r--r-- | skills/pi-browser-harness/SKILL.md | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/skills/pi-browser-harness/SKILL.md b/skills/pi-browser-harness/SKILL.md index f0a3324..e3bf7dc 100644 --- a/skills/pi-browser-harness/SKILL.md +++ b/skills/pi-browser-harness/SKILL.md @@ -76,6 +76,14 @@ it by opening tabs elsewhere — a different profile means different accounts. You're attached to the user's real Chrome — never launch your own. If auth is required, stop and ask the user. If `browser_page_info` returns a dialog, handle it first with `browser_handle_dialog`. +## Downloads land in the user's context + +`browser_download` calls `Browser.setDownloadBehavior` with no `browserContextId`, which Chrome applies to its **default browser context** — the same one the user's own tabs are in. The override redirects the user's manual downloads too, and it lives on the browser connection the daemon keeps open, so it outlives the tab and the pi session. Symptom the user reports: *"I download things in Chrome and nothing appears in Downloads."* + +A clean session shutdown restores the default; a killed session does not. Call `browser_download({ restore: true })` as soon as you are done with a download path, and if a user reports the symptom, call it first. + +`browser_run_script` is the same hazard: a script that sets download behavior and then throws partway leaves Chrome mutated. Reset it in a `finally`, not after the last line. + ## Diagnosing a "nothing happened" moment When an action runs but the page didn't change, capture `browser_console`'s `nextCursor` *before* the action, take the action, then call `browser_console({ sinceSeq: <cursor> })` after — this isolates what your action caused from what was already there. Pair with `browser_network_requests({ sinceMs: 5000 })` to see if an API call fired and failed. The console buffer is page-scoped: it clears on tab switch, capacity 500. |