Summary
In a live BSK session connected to Chrome, navigating Zoho CRM and filtering Accounts by name worked. Clicking the matching account link then failed at the tool boundary with authorization channel closed. The BSK session still appeared active afterward, and a fresh observation showed the same results page. No CRM records were changed.
Environment
Windows; PowerShell 7.6.6
Chrome 154.0.0.0
BrowserSkill extension 0.3.1; protocol 1.3
BSK browser instance 472b94c5, label onlinkservices
Daemon had to be started with bsk daemon start --foreground; ordinary bsk daemon start failed with a Windows Job Object breakaway error.
Daemon startup logged background=false in_job=Ok(true) and reported ready.
Session used an agent-owned tab; no user tab was borrowed. Borrow confirmation was enabled.
Steps to reproduce
Start the BSK daemon in a persistent PowerShell window with bsk daemon start --foreground.
Start a session bound to the connected browser instance.
Navigate to Zoho CRM’s Accounts module.
Filter Accounts by Account Name using “contains” and a company name.
Confirm the Accounts list displays the matching result.
Using a fresh ref from bsk observe, click the account link.
Expected
The account detail page opens, or BSK returns a structured permission/confirmation error with guidance.
Actual
The click call returned authorization channel closed without a BSK JSON response. The session was still listed afterward, and observing again showed the same Accounts result.
Important distinction
A later retry was canceled by the caller and should not be treated as a second BSK failure. The first authorization-channel error is the reproducible issue observed here. The Account Name filter itself worked.
Possible fixes to investigate
Preserve or re-establish the browser-control authorization channel for actions in an active session.
Return a structured error distinguishing channel disconnect, denied confirmation, and caller cancellation instead of the generic message.
Add diagnostics tying the failed action to its session, tab, browser instance, and authorization/confirmation state.
Check whether Windows Job Object association (in_job=true) can cause control-channel lifetime issues for foreground daemons.
Ensure agent-owned-tab actions do not incorrectly wait on a user-tab borrowing confirmation.
Impact
Read-only account search worked, but opening the result to inspect account details was blocked. No Zoho data was modified. The message appeared at the tool boundary, so it may involve the BSK–agent integration as well as BSK itself.
Summary
In a live BSK session connected to Chrome, navigating Zoho CRM and filtering Accounts by name worked. Clicking the matching account link then failed at the tool boundary with authorization channel closed. The BSK session still appeared active afterward, and a fresh observation showed the same results page. No CRM records were changed.
Environment
Windows; PowerShell 7.6.6
Chrome 154.0.0.0
BrowserSkill extension 0.3.1; protocol 1.3
BSK browser instance 472b94c5, label onlinkservices
Daemon had to be started with bsk daemon start --foreground; ordinary bsk daemon start failed with a Windows Job Object breakaway error.
Daemon startup logged background=false in_job=Ok(true) and reported ready.
Session used an agent-owned tab; no user tab was borrowed. Borrow confirmation was enabled.
Steps to reproduce
Start the BSK daemon in a persistent PowerShell window with bsk daemon start --foreground.
Start a session bound to the connected browser instance.
Navigate to Zoho CRM’s Accounts module.
Filter Accounts by Account Name using “contains” and a company name.
Confirm the Accounts list displays the matching result.
Using a fresh ref from bsk observe, click the account link.
Expected
The account detail page opens, or BSK returns a structured permission/confirmation error with guidance.
Actual
The click call returned authorization channel closed without a BSK JSON response. The session was still listed afterward, and observing again showed the same Accounts result.
Important distinction
A later retry was canceled by the caller and should not be treated as a second BSK failure. The first authorization-channel error is the reproducible issue observed here. The Account Name filter itself worked.
Possible fixes to investigate
Preserve or re-establish the browser-control authorization channel for actions in an active session.
Return a structured error distinguishing channel disconnect, denied confirmation, and caller cancellation instead of the generic message.
Add diagnostics tying the failed action to its session, tab, browser instance, and authorization/confirmation state.
Check whether Windows Job Object association (in_job=true) can cause control-channel lifetime issues for foreground daemons.
Ensure agent-owned-tab actions do not incorrectly wait on a user-tab borrowing confirmation.
Impact
Read-only account search worked, but opening the result to inspect account details was blocked. No Zoho data was modified. The message appeared at the tool boundary, so it may involve the BSK–agent integration as well as BSK itself.