`bsk tab borrow` approval is misrouted as "cancel" when Allow is clicked on the desktop notification (WorkBuddy integration)

[alex14563]

Environment

• OS: Windows 11 (i7-1165G7 / 32GB)
• Host: WorkBuddy desktop client
• BrowserSkill extension: 0.1.6; bsk CLI: 0.1.10; daemon protocol: 1.0
• Browser: Chrome 149.0.0.0 (logged-in user profile)
• Health: bsk doctor reports 6/6 ok (daemon running, protocol compatible, extension connected, browser protocol compatible)

Steps to reproduce

1. bsk session start → obtain session id (e.g. epxb)
2. bsk tab list --session <sid> --scope user → obtain target tab id (e.g. 1345701750)
3. bsk tab borrow <tab-id> --session <sid>
4. A desktop toast notification requesting approval appears in the bottom-right corner; click Allow
5. Observe the bsk output

Expected
Clicking Allow borrows the user tab into the Agent Window; bsk tab borrow returns success and the tab can then be inspected/operated via snapshot / click / fill.

Actual
bsk tab borrow returns immediately with:

error: operation cancelled
hint: the previous command was interrupted (Ctrl-C or a remote `cancel` request)
details: tab_borrow cancelled by user

The tab is not borrowed (bsk tab return then reports tab ... is not borrowed by this session). Reproduced consistently across 3 attempts.

Diagnosis & root cause

• Source of the cancel signal: bsk labels the failure as a remote cancel request (origin: client/harness side), not a daemon-initiated cancel.
• ~/.bsk/daemon.log.2026-08-19 contains zero borrow/cancel entries. This rules out both the bsk daemon and the browser extension as the cancel origin, leaving the WorkBuddy frontend as the source of the cancel signal.
• Inference: the borrow approval is surfaced as a desktop toast notification. Clicking Allow on that toast is not mapped to bsk's approval channel and is instead relayed back to bsk as a cancel by the WorkBuddy frontend. The user action itself was correct (Allow was genuinely clicked).

Evidence summary

• bsk doctor: 6/6 ok, no version-skew warning.
• bsk browsers: EXT 0.1.6, extension connected.
• bsk tab borrow: 3/3 attempts → cancelled by user / remote cancel request.
• bsk daemon log: 0 borrow/cancel entries.

Impact

• The core capability of browser-skill — operating a user's already-logged-in tab — is unavailable under the current WorkBuddy integration.
• Public pages can be worked around via bsk tab create --url + navigate in the Agent Window, but any page requiring an authenticated session cannot be operated.

Suggested fixes

1. Fix the WorkBuddy frontend mapping of the borrow-approval toast click: route Allow to an approve signal instead of cancel.
2. Alternatively, present borrow approval as an in-browser overlay panel (explicit Allow/Cancel on the relevant Agent Window tab) rather than relying on the fragile desktop-notification callback path.
3. Add borrow-approval event logging on the bsk daemon side (with source and outcome) to ease future diagnosis of such approval-channel issues.