feat(computer-use): user-facing authorization for cua-driver browser attachment (browser-approve token + bounded manifest mode) - #86342
Conversation
…attachment Completes the typed cua_browser_* route (PR #74166 lineage) with the authorization surface that makes existing-profile attachment and repeatable bounded automation reachable by real users: - hermes computer-use browser-approve: CLI passthrough that mints cua-driver's five-minute single-use attachment token for one exact (pid, window_id). The user, never the model, is the token source. - approval_token passthrough on cua_browser_prepare (schema + dispatch + browser_route), forwarded only for existing_profile and only as a non-empty string. - computer_use.permission_mode: bounded + capability_manifest config: private per-session embedded daemon launched with --capability-manifest/--approve-capability-manifest; missing manifest fails loudly. 'unrestricted' is deliberately NOT a config value — it stays bound to the explicit per-session YOLO toggle. - Skill + system-prompt + docs guidance for the three authorization rungs and the isolated-profile-first default. E2E-verified against a temp HERMES_HOME: real config resolution to bounded, loud failure without a manifest, real argparse path driving a fake cua-driver binary, standard default preserved.
|
Warning Review limit reached
Next review available in: 17 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
Comment |
૮ >ﻌ< ა ci reviewran on 9e1822c — fix(computer-use): align browser authorization with live-ver
|
alt-glitch
added
type/feature
…-driver 0.19.3 contract Live-tested against the real cua-driver 0.19.3 binary (Linux x86_64): - bounded serve flags corrected: the daemon accepts --session-policy/--approve-session-policy, not the docs' --capability-manifest names (which it rejects). Verified end-to-end: a bounded daemon with a real policy file starts and reports running. - browser-approve verified real but interactive-only (refuses without a TTY) and its token is a legacy compatibility path disabled by default on current drivers (per the live browser_prepare schema). Kept as a passthrough; no longer presented as the primary route. - NEW primary standard-mode route, verified live: launch the runtime with cua-driver's trusted-launcher grant. config opt-in computer_use.grant_existing_profile: true appends --grant existing-profile to the standard-mode MCP spawn (MCP initialize verified accepting the flag). Default false = attachment keeps failing closed. Never applied to bounded/unrestricted daemons. - Skill, system prompt, tool schema, and docs updated to the verified ladder: config grant > bounded manifest > YOLO; token = legacy.
2 participants
Summary
The typed
cua_browser_*route (landed in #74166) can now actually attach to a user's signed-in browser and run repeatable bounded automation: this PR adds the user-facing authorization surface, live-verified against a real cua-driver 0.19.3 binary — a one-timecomputer_use.grant_existing_profileconfig opt-in (cua's trusted-launcher--grant existing-profile), aboundedpermission mode driven by a reviewed session-policy manifest, and ahermes computer-use browser-approvetoken passthrough for driver builds where the legacy token path is enabled.Until now,
existing_profileattachment always failed closed in standard mode and the only escape hatch was full session YOLO. This wires up cua-driver's intended non-YOLO authorization paths end to end.Changes
tools/computer_use/cua_backend.py:computer_use.grant_existing_profile: trueappends--grant existing-profileto the standard-mode MCP spawn — the supported route for signed-in-browser attachment on current drivers (live-verified: MCP initialize accepts the flag). Defaultfalsekeeps attachment failing closed. Never applied to bounded/unrestricted daemons._EmbeddedCuaDaemonsupportsbounded: private per-session daemon launched with--session-policy <path> --approve-session-policy(live-verified flag names — the docs'--capability-manifestspelling is rejected by the real binary); missing manifest fails loudly at session start.hermes_cli/config_defaults.py:computer_use.permission_mode(standard|bounded),capability_manifest,grant_existing_profile.unrestrictedis deliberately NOT a config value — it stays bound to the explicit per-session YOLO toggle; session YOLO still overrides bounded.hermes_cli/main.py:hermes computer-use browser-approve --pid --window-id --profile-modeinteractive passthrough. Live-verified: the verb exists, requires--pid, and refuses non-interactive terminals (genuinely un-mintable by a model). Current drivers treat its token as a disabled legacy compatibility path, so it's surfaced as secondary.tools/computer_use/browser_route.py+tool.py+schema.py:approval_tokenaccepted oncua_browser_prepare, forwarded only forexisting_profileand only as a non-empty string.computer-useskill, system-prompt typed-browser section, and docs describe the verified ladder — config grant → bounded manifest → YOLO — with isolated-profile-first as the default posture and refusals reported to the user by config key.tests/tools/test_computer_use_browser_authorization.py(26 new) covering the grant flag, token passthrough + non-string rejection, bounded daemon spawn args, no-bypass-env invariant, config resolution incl.unrestricted-in-config rejection, and backend construction.Validation
browser-approveverb--pid; refuses non-TTYstatusreports running; wrong flag names / policy formats rejected loudlycua-driver mcp --grant existing-profilebrowser_prepareschema on 0.19.3approval_token= legacy path; trusted-launcher grant = supported route (drove the design)browser-approvepath, standard defaultNot live-testable here: the final GUI attach to a running signed-in Chrome (headless box, no display). Flags, daemon startup, schema contract, and grant acceptance are all verified against the real driver; the display-dependent hop needs one run on a desktop box.
Infographic