mirror of
https://github.com/jackwener/OpenCLI.git
synced 2026-09-14 18:25:42 +08:00
jakevin
9387cd9262
* fix(browser): stale default profile must not veto live connections A persisted default profile (browser-profiles.json defaultContextId) has a lifetime that routinely exceeds the extension instance it names — reinstalling the extension or resetting Chrome regenerates the contextId. Since #1235 that stale preference was folded together with --profile/OPENCLI_PROFILE into one hard contextId on every command, so the daemon refused to serve it (profile_disconnected) even when exactly one live profile was connected, breaking the documented promise "with only one connected profile, OpenCLI uses it automatically" — and making doctor hang waiting for a dead profile. First-principles fix: distinguish REQUIREMENT from PREFERENCE end to end and let the component that knows live state arbitrate. - profile.ts resolves a ProfileSelection tagged 'explicit' (--profile arg, OPENCLI_PROFILE env — fail loud when offline) or 'preferred' (config default); profileRouteParams() maps it to the wire fields. - New wire field preferredContextId (both protocol copies); contextId keeps its strict semantics. Old daemons ignore the new field, which degrades to the no-contextId single-profile auto-use — exactly the documented behavior. - The daemon arbitrates via a pure, tested resolveProfileRoute(): requested → strict; preferred → use when connected, fall back to the only connected profile when not (logged once per stale id), ask with a stale-default hint when multiple are connected. - bridge/ensure only pin readiness to a profile for explicit requirements — a stale preference no longer makes connect()/doctor wait for a dead profile. - doctor surfaces the stale default with the fallback status and the recovery command (opencli profile use). * fix(cli): key saved-tab scope by the selected profile in getPageScope From adversarial review: getBrowserPage computed the target scope from the profile SELECTION (explicit or preferred), but getPageScope read only the explicit Page.contextId — so with a config-default profile the remembered tab was saved under "<session>" and looked up under "<contextId>:<session>", silently forgetting the selection on every command. Both sites now key the scope by the selected profile.
OpenCLI Browser Bridge Extension
The extension connects Chrome tabs to the local OpenCLI daemon. It uses Chrome extension APIs only as a transport and browser-control layer for explicit CLI commands.
Permission Notes
debugger: sends CDP commands to OpenCLI-controlled or bound tabs.tabs/tabGroups: manages the dedicated OpenCLI automation container and reports selected tab metadata back to the CLI.cookies: reads cookies for browser-backed adapters that need authenticated fetches.downloads: surfaces download lifecycle toopencli browser wait download. The extension observes started / in-progress / completed / failed downloads so the CLI can wait for a file triggered by an automation command. OpenCLI filters by the command's filename/URL pattern and timeout, and does not modify, redirect, or persist browser download history.
Suggested Chrome Web Store justification for downloads:
This extension uses
chrome.downloadsto surface download lifecycle (started / in-progress / completed / failed) to the OpenCLI command-line tool, so agents can wait for downloads triggered during an automation workflow. The command filters by a user-provided filename or URL pattern and timeout. We do not modify, redirect, or persist user download history.