[Bug]: concurrent bsk download from another session fails at once with invalid_params "another bsk download is active" instead of queueing or running in parallel #519

Prerequisites

• I have searched existing open and closed issues to ensure this is not a duplicate. The closest is [Bug] A stalled download click ignores timeout/cancellation and blocks subsequent downloads #347, closed, which is about a stalled click holding the gate.
• I have verified that all sensitive data has been redacted.

BrowserSkill Version or Commit

CLI 0.3.3, extension 0.3.3, protocol 1.3 (source tag cli-v0.3.3, d9a78ae)

Operating System

Windows 11

OS Details and Architecture

Windows 11 Pro 10.0.26300 x64

Browser and Browser Extension Version

Microsoft Edge 156 / BrowserSkill extension 0.3.3

Exact Command or API Call

# session A and session B are two independent sessions on the same browser instance
bsk download --json --selector "#slow" --out out/a.bin --session A   # still running
bsk download --json --selector "#fast" --out out/b.bin --session B   # started 1.5 s later

Summary

Several agents share one browser through separate sessions; each session has its own Agent Window. Every command runs concurrently across sessions except bsk download.

While any session's download is in progress, a bsk download from any other session fails immediately:

{
  "code": "invalid_params",
  "message": "another bsk download is active",
  "hint": "check your command arguments; run `bsk <cmd> --help` to see the expected format",
  "exit_code": 1
}

The cause is the module-level downloadActive flag in apps/extension/src/tools/download.ts, which wraps the browser-global chrome.downloads transaction.

Steps to Reproduce

1. Serve a page from 127.0.0.1 with two links:
   • #slow: an attachment whose response is delayed 5 s, sent with Content-Disposition: attachment;
   • #fast: an attachment with no delay.
2. Start two sessions, A and B, and navigate both to the page.
3. Run bsk download on #slow in session A. While it runs, run bsk download on #fast in session B.

Expected Behavior

One of the following, in order of preference:

1. Concurrent captures for different sessions or tabs. Attribution already keys on the CDP target plus the intent URL and suggested filename, so only a genuinely ambiguous candidate needs to fail closed.
2. Otherwise, B waits for the gate inside its own timeout_ms (a FIFO queue) and then runs.
3. At minimum, a dedicated, documented busy result with effect_state: none and a retry hint, instead of invalid_params with "check your command arguments".

Actual Behavior

B fails within about 1 s with invalid_params while A completes normally (20,000 bytes). The check runs before session lookup and before any click, so this error has no page effect. Callers cannot know that from the code or the hint: the generic download guidance says "do not retry blindly", so agents treat it as a hard failure.

With several agents sharing one browser (for example one generating images on one site while another exports models on another), downloads fail whenever two of them overlap. Every caller then needs its own cross-process lock and retry wrapper.

Additional Context

Without overlap, sequential downloads in one tab and fetch-then-blob anchor downloads work reliably (four sequential attachment downloads and three blob downloads, each about 1 s).

Separately, we see intermittent download_capture_failed / phase=attribution / effect_state=unknown timeouts on ChatGPT and Gemini image viewers. The same control succeeds minutes later. We will file that separately once we have a reproduction.