feat(browser): add durable native-window capability namespaces - #648
feat(browser): add durable native-window capability namespaces#648steipete wants to merge 14 commits into
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
PR SummaryHigh Risk Overview Every namespace call must supply On the agent/runtime side, Chrome channel resolution can retain a read-only DevTools control WebSocket for exact tab/window correlation; Reviewed by Cursor Bugbot for commit d0b807e. Bugbot is set up for automated code reviews on this repo. Configure here. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 0ec6ae7. Configure here.
| return BrowserCLINamespaceCreateResult( | ||
| namespaceReceiptData: receiptData, | ||
| response: .text("Browser capability namespace created.") | ||
| ) |
There was a problem hiding this comment.
Create throw leaks remote namespace
Medium Severity
createNamespace creates the Bridge namespace first and only then canonicalizes the receipt. If that second step throws, BrowserCLINamespaceLifecycle.create never sees a receipt and does not roll back, so the host namespace stays live until it expires. Callers can retry and create another one, leaving unpersisted namespaces that cannot be closed.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 0ec6ae7. Configure here.
clawsweeper
Bot
added
merge-risk: 🚨 availability
|
Codex review: needs real behavior proof before merge. Reviewed August 27, 2026, 4:57 AM ET / 08:57 UTC. ClawSweeper reviewWhat this changesThe PR adds Bridge 1.38 browser namespaces that persist authenticated browser authority across CLI invocations and can bind opaque pages to an exact native Chrome window. Merge readiness⛔ Blocked until real behavior proof from a real setup is added - 6 items remain Keep this collaborator-authored feature PR open for maintainer product review, repair of one remaining lifecycle bug, and authority-chain runtime proof. Priority: P2 Review scores
Verification
Live VerificationCommand: Result: FAIL (failed) — step 1 Assertions:
How this fits togetherPeekaboo’s CLI and MCP browser tools send Chrome actions through a local authenticated Bridge host. The new namespace layer stores caller-scoped authority between CLI invocations, then revalidates the Chrome/window relationship before a bound mutation reaches the provider. flowchart LR
CLI[CLI browser command] --> Receipt[Owner-private receipt]
Receipt --> Bridge[Authenticated Bridge host]
Bridge --> Namespace[Caller-scoped namespace]
Namespace --> Binding[Native window validation]
Binding --> Provider[Chrome provider action]
Provider --> Result[Sanitized result]
Decision needed
Why: This adds a new persistent browser-authority capability rather than repairing an established contract, and source review cannot establish long-term product ownership of that surface. Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Retain the scoped, fail-closed namespace design after closing the allocation cleanup gap and demonstrating its allowed and denied authority paths against a real Bridge and Chrome session. Do we have a high-confidence way to reproduce the issue? No live reproduction was supplied, but source inspection gives a high-confidence fault path: remote creation succeeds before receipt validation/canonicalization can throw, while lifecycle rollback only receives successful adapter results. Is this the best way to solve the issue? No; the scoped design is plausible, but it needs post-create cleanup coverage and real final-effect authority proof before it is the safe maintainable solution. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against e55661a32aea. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
Maintainer decision for the 4.3.0 queue: keep this PR open, but leave the durable namespace/native-window feature out of 4.3.0. Its branch and implementation remain available for follow-up; this is a scope deferral, not a duplicate/already-fixed closure. The smaller foreground-only DOM-click work in #660 is being handled separately. Before this feature lands later, it still needs reconciliation with current browser ownership/foreground semantics, allocation-failure cleanup, and the corresponding allowed/refused native-window proof. No release publication or successful live qualification is claimed by this update. |
Refresh PR #660 on current browser ownership and foreground policy. Add the explicit synthetic DOM-click route through existing capability and receipt validation, correct Agent guidance, and document its limits. Do not treat HTMLElement.click as trusted pointer input or background-safe. Preserve current signer/session/target/dispatch invariants and keep the separate durable namespace proposal in #648 out of this change. Run the browser capability, remote-session, and guidance regressions in CI. Scoped syntax, formatting, lint, static guidance and workflow contracts passed; updated-scope Codex P0 review is clean. Swift execution and real browser final-effect proof remain pending; the PR stays draft.
Refresh PR #660 on current browser ownership and foreground policy. Add the explicit synthetic DOM-click route through existing capability and receipt validation, correct Agent guidance, and document its limits. Do not treat HTMLElement.click as trusted pointer input or background-safe. Preserve current signer/session/target/dispatch invariants and keep the separate durable namespace proposal in #648 out of this change. Run the browser capability, remote-session, and guidance regressions in CI. Scoped syntax, formatting, lint, static guidance and workflow contracts passed; updated-scope Codex P0 review is clean. Swift execution and real browser final-effect proof remain pending; the PR stays draft.
1 participant
Summary
Durable CLI namespace calls require the exact issuing
--bridge-socketon every invocation. Explicit DevTools endpoints receive only opaque namespace/generation/connection-receipt-digest attribution. Namespace operations disappear from negotiation if runtime preparation fails.Stack and proof
This PR is stacked directly on #647 at exact base
d4d1902823fff0d8edf640f5b74358bf537c22ba. Nine of the twelve replayed native/Bridge commits are exactgit range-diff =matches. The three differing commits contain only reviewed additive unions for the inherited changelog, installed-application client capability negotiation, and ScreenCaptureKit ownership preparation plus Bridge lifecycle generation. Follow-up commit0ec6ae75f0a470df03117a03c25a694036be4d88closes the P0–P2 findings found by current-stack review.Source-only proof:
The repository's normal macOS and CodeQL workflows are main-only and are intentionally suppressed while this stacked PR targets
codex/installed-app-parity-after-browser-645; they will not run on this branch relationship. No Swift/Xcode build or UI test was run for this source-only replay, as requested. No AppleScript/JXA/OSA or virtualization was used.