Skip to content

feat(core): refuse Chrome downloads as Agent download - #175

Open
cursor[bot] wants to merge 2 commits into
mainfrom
cursor/bc-fb7d6c9e-f364-4c0a-bda6-ab0afe7b6b31-cfc4
Open

feat(core): refuse Chrome downloads as Agent download#175
cursor[bot] wants to merge 2 commits into
mainfrom
cursor/bc-fb7d6c9e-f364-4c0a-bda6-ab0afe7b6b31-cfc4

Conversation

@cursor

@cursor cursor Bot commented Aug 16, 2026

Copy link
Copy Markdown

Buyer-visible gap

Partial implementation of #27. Active PR #43 can prove that pinned Chromium exercises chrome.downloads. That compatibility proof must not become OriginWeave Agent Capability::Download or filesystem authority. Protected main already evaluates explicit extension-to-Agent grants, but adapters had no reusable function that refuses a Chrome permission string as Agent action authority.

Current exact implemented boundary

Protected main is exact 0c376acf059be9ddddddfbde1d0189e4f39ef014; current exact contributor head is 52e42370ce49ad6142fb19eb0211f43716f19803.

This active PR adds chrome_permission_authorizes_agent_action in originweave-core:

  • reviewed Chrome compatibility permissions (downloads, bookmarks, history, storage, tabs, scripting, sidePanel, declarativeNetRequest, declarativeNetRequestWithHostAccess) return CompatibilitySurfaceOnly;
  • empty, hostile, case-shifted, or unrecognized permission tokens return UnrecognizedPermission;
  • the function never returns Ok, so a Chrome permission cannot mint any Agent action including Download.

This is IMPLEMENTED_ON_ACTIVE_PR, not protected-main shipped truth. This PR does not implement HTTP/1.1 (#37), revocation freshness (#48), MV3 downloads (#43), or a Chromium adapter.

TDD and documentation-truth repair

The first test-only compile failed because ChromePermissionAuthorityError and chrome_permission_authorizes_agent_action did not exist. The production function was added after that RED.

A later exact-head review found that docs/traceability/extension-authority-security.md had incorrectly placed this PR-only function under “Protected main already provides”. Current head 52e42370ce49ad6142fb19eb0211f43716f19803 repairs the documentation truth boundary: protected-main capabilities remain listed separately and PR #175 is explicitly IMPLEMENTED_ON_ACTIVE_PR. The same dossier also refreshes the exact active evidence for PRs #62/#63 without claiming those branches as shipped. No production behavior or gate was weakened.

Exact-current gate state

On unchanged exact head 52e42370ce49ad6142fb19eb0211f43716f19803:

  • CI run 31969518244: success;
  • Manifest V3 Compatibility run 31969518201: success;
  • SAST Semgrep run 31969518285: currently queued, not passing evidence;
  • Security Scan run 31969518231: currently queued, not passing evidence;
  • GitHub reports the PR mergeable and Ready; and
  • the earlier CHANGES_REQUESTED review was submitted against predecessor head f6c089b8faae015c5b8845296af7cdc3ddcd0c65; it is historical evidence after the repairing push and is not converted into approval.

The repeated unassigned-runner queue class is already routed to the organization control-plane incident ContextualWisdomLab/.github#712; this clean head is not mutated merely to retrigger scanners.

Integration gate

The active organization ruleset requires one qualifying approving review, dismisses stale reviews on push, requires latest-push approval, and requires review-thread resolution. Because this scheduled actor made the latest repairing push, it cannot supply the qualifying independent/latest-push approval. Required central workflows remain enforced independently from review state.

Keep this PR Ready until every applicable exact-head required workflow and a legitimate independent/latest-push approval are satisfied. Do not fold this into the downloads runner, #37, or reserved MV3 descendant lanes.

Standards

Chrome for Developers. (n.d.). chrome.downloads. Google. Retrieved August 16, 2026, from https://developer.chrome.com/docs/extensions/reference/api/downloads

Scope boundary

This fail-closed primitive separates Chrome compatibility permission from OriginWeave Agent action authority. It does not itself install an extension, parse Chrome messages, launch Chromium, grant filesystem authority, or prove the full #27 runtime boundary.

This scheduled actor does not merge, self-approve, tag, publish, alter workflows, add secrets, or weaken checks.

Partial implementation of #27.

A Chrome downloads permission is compatibility evidence only. Adapters
must fail closed before treating it as Capability::Download.

Co-authored-by: Seongho Bae <[email protected]>

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Review — exact head f6c089b8faae015c5b8845296af7cdc3ddcd0c65

chrome_permission_authorizes_agent_action is fail-closed: a Chrome downloads token, and every other reviewed compatibility permission, cannot authorize Agent Download or any other ActionKind. Case, empty, and control-bearing tokens stay UnrecognizedPermission. That is the correct adapter check for ADR 0013 rule 4.

Next action: keep this primitive independent of MV3 runner PRs #43/#176. Do not treat a passing Chrome fixture as Agent filesystem authority. Wire adapters to call this boundary before policy, and add commands and windows to the reviewed-token list when those protected-main surfaces should be classified as CompatibilitySurfaceOnly instead of UnrecognizedPermission. Both paths already refuse the action.

Rust contracts, production coverage, and the pinned Chrome MV3 fixture succeeded on this head at review time. Remaining SAST/security/Strix/review workflows were still queued and are not promoted. This review is not an approval.

View PR

Open in Web View Automation 

Sent by Cursor Automation: Fix Issues

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review — exact head f6c089b8faae015c5b8845296af7cdc3ddcd0c65

The isolation primitive is sound and independent of the #43/#176 downloads runner. chrome_permission_authorizes_agent_action never returns Ok. Reviewed Chrome tokens including downloads become CompatibilitySurfaceOnly. Empty, case-shifted, newline-injected, and unrecognized tokens become UnrecognizedPermission. The ActionKind argument is intentionally unused so a Chrome permission cannot mint Download or any other Agent action.

is_exact_chrome_permission_token correctly admits mixed-case Chrome names such as sidePanel and declarativeNetRequest while rejecting DOWNLOADS and host-permission punctuation.

Residual, non-blocking

Protected-main MV3 evidence also exercises windows and commands. Those names are not in REVIEWED_CHROME_COMPATIBILITY_PERMISSIONS, so they currently classify as UnrecognizedPermission rather than CompatibilitySurfaceOnly. Both arms still refuse Agent authority. Add them only if an adapter needs the clearer diagnostic; do not treat the omission as a capability leak.

Stay draft until exact-head required checks are green. Do not fold this into the downloads runner, HTTP #37, or reserved MV3 drafts #49/#56/#59/#60/#61.

Open in Web View Automation 

Sent by Cursor Automation: Fix Issues

@cursor

cursor Bot commented Aug 16, 2026

Copy link
Copy Markdown
Author

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

@seonghobae
seonghobae requested review from seonghobae and removed request for seonghobae August 16, 2026 19:06

@seonghobae seonghobae left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exact-head review found one current documentation-truth defect that must be fixed before approval. docs/traceability/extension-authority-security.md adds chrome_permission_authorizes_agent_action under the heading “Protected main already provides:”, but protected main is still 0c376acf059be9ddddddfbde1d0189e4f39ef014 and does not contain this PR-only function. That promotes active-PR behavior to shipped truth and violates the repository’s protected-main-vs-active-PR documentation contract. Keep the existing protected-main bullets unchanged and move/label this function as active/non-shipped PR #175 evidence (and make the docs/traceability/README.md wording equally explicit if needed). The Rust fail-closed implementation itself looks coherent on this head; exact-head CI, MV3, SAST, and Security are green. Please repair the truth-status wording without widening scope, then re-run exact-head evidence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants