fix(desktop): let sites copy to the clipboard in the browser tab - #6696
Conversation
The agent partition denied every site permission, which included clipboard-sanitized-write — the permission Chromium routes navigator.clipboard.writeText through. Copy buttons rejected with NotAllowedError and did nothing at all: no error, no copied text. Sites still on document.execCommand('copy') kept working, which is why only some looked broken.
Granting it hands the page no reach it lacked. Chromium still requires the document to be focused and holding a transient user activation, and a sanitized write only places text the page already renders onto the clipboard. Reading stays denied, along with media, geolocation, and notifications.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
PR SummaryLow Risk Overview
Unit tests assert the grant/deny split on both the permission request and check handlers. Reviewed by Cursor Bugbot for commit 12e7939. Configure here. |
Greptile SummaryThe PR updates the desktop agent-browser partition to permit sanitized clipboard writes while continuing to deny clipboard reads and all other site permissions.
Confidence Score: 5/5The PR appears safe to merge because it narrowly restores user-activated clipboard copying without enabling clipboard reads or other sensitive site permissions. The production handlers consistently use the same single-entry allowlist, and the tests cover both permission-handler paths and the sensitive permissions that must remain denied.
|
| Filename | Overview |
|---|---|
| apps/desktop/src/main/browser-agent/session.ts | Replaces blanket permission denial with an exact sanitized-write allowlist while retaining default denial for every other permission. |
| apps/desktop/src/main/browser-agent/session.test.ts | Verifies both request and check handlers grant sanitized clipboard writes and reject representative sensitive permissions. |
Reviews (1): Last reviewed commit: "fix(desktop): let sites copy to the clip..." | Re-trigger Greptile
Summary
clipboard-sanitized-write— the permission Chromium routesnavigator.clipboard.writeTextthrough. Copy buttons rejected withNotAllowedErrorand did nothing at all: no error shown, nothing copied.document.execCommand('copy')kept working, which is why only some sites looked broken and the cause wasn't obvious.Granting it hands the page no reach it lacked: Chromium still requires the document to be focused and holding a transient user activation, and a sanitized write only places text the page already renders onto the clipboard. Clipboard read is the direction that would leak whatever the user last copied from anywhere else — that stays denied.
Type of Change
Testing
Measured against the app's exact partition configuration on a real Electron 43.1.1 runtime, with transient user activation (as a real copy-button click has):
Before —
navigator.clipboard.writeText→rejected: NotAllowedError Failed to execute 'writeText' on 'Clipboard': Write permission denied, andnavigator.permissions.query({name:'clipboard-write'})→denied.After —
writeText→resolved, permission query →granted, and the text actually landed on the system clipboard. Re-checked in the same run that the rest stay denied:clipboard.readText()→NotAllowedError,Notification.requestPermission()→denied,geolocation.getCurrentPosition→denied: code 1.Unit test asserts the grant/deny split across
media,geolocation,notifications,clipboard-read(denied) andclipboard-sanitized-write(granted); confirmed it fails when the fix is reverted. Type-check and lint pass.Note: repo CI has been cancelling at
Install dependencieson every branch includingstagingfor several hours, so the CI signal here is unrelated to this change.Checklist