This Week in Extensibility: the Chrome Web Store bans two extension categories, Mozilla proposes a permission model for AI agents, Cloudflare runs customer code before signup

2026-07-17T00:00:00-04:00

The week was about boundaries, not new capabilities. The Chrome Web Store banned two categories of extension outright and tightened what the rest may collect, Mozilla floated a permission model to rein in AI agents, and the one capability that actually shipped, Cloudflare running a customer's code before signup, is itself a piece of tenant isolation.

Governance: the Chrome Web Store narrows data collection and bans two extension categories

Google published a Chrome Web Store policy update, effective August 1, that bans two categories of extension outright. Out: extensions that facilitate real-money bets on predicted outcomes, and extensions built to bypass the safety guardrails or usage limits of AI services. The updated policies also tighten Limited Use for every listing: an extension may collect only data strictly necessary to its disclosed single purpose, and developers must disclose any change to their data handling after install.

Why it matters: the store is the chokepoint for a large cross-browser extension ecosystem, so its policy text sets what an extension is allowed to be. The data rules move the baseline; the two bans are Google taking a side on specific uses. This is announced policy, not yet enforced: compliance action starts August 1, with no grace period after it.

Standards: a permission model for AI agents, and isolation keys for extension pages

Mozilla opened a proposal for a browser-mediated permission model for AI agents at the WebExtensions Community Group. Filed July 6 by Mozilla's c-nar, the issue argues agent access today is all-or-nothing and declarative rather than enforced, and sketches WebExtensions-style request/grant/revoke/audit primitives so a user could scope an agent's reach and revoke it mid-action. The open question, posed in the issue itself: does an agent permission lifecycle belong in WebExtensions or on the wider web platform? It awaits triage from Chrome, Firefox, and Safari. A separate July 4 proposal would add cross-origin isolation manifest keys to extension pages, unlocking SharedArrayBuffer and multithreaded WebAssembly for uses like on-device inference; Chrome already ships it, Safari and Firefox are supportive, and Firefox is blocked on process-model work.

Why it matters: both move the boundary of what an extension or agent may touch, and both are early. Mozilla's names a real gap, enforced and revocable agent permissions, but it is a scoping question, not an agreed work item. The isolation keys have all three engines supportive yet no spec text.

Agentic web: WebMCP debates batched and persistent tools

WebMCP debated two questions about how a page's tools run. WebMCP lets a website expose in-page tools for a user's agent to call; it is in a Chrome origin trial, not a shipping default. A July 14 proposal for a code mode execute_tools batch primitive would let an agent run several registered tools in one call, cutting roundtrips and token use. A July 9 thread proposes worker-backed tools that survive a page navigation and run without a visible tab.

Why it matters: batching and persistence point the same way, agents doing more per page and across navigations. Both are Community Group issues layered on a single-vendor origin trial, so this is direction, not capability.

Infrastructure: Cloudflare runs customer code before signup

Cloudflare Workers for Platforms added a Temporary Accounts API. The new API, shipped July 14, lets a platform provision a preview account and deploy a live Worker before the end user signs in, then hand them a claim URL to make it permanent. Workers for Platforms is the multi-tenant layer a product uses to run its own customers' code in isolation; Cloudflare aims this at coding and agent platforms that generate a working app first and ask for the signup second.

Why it matters: the one thing that actually shipped this week, and it removes a step: a customer's generated or customized code can run in an isolated sandbox before they have an account. A small change to the onboarding edge of the isolation layer that customization products build on.

Also worth knowing

The WebAssembly Community Group put multibyte array access to a phase-2 vote at its July 14 call, a proposal for efficient multi-byte loads and stores over byte arrays. Minutes are not yet posted, so the outcome is unconfirmed.

Local-First Conf 2026 ran in Berlin July 12–14, closing with an Ink & Switch Lab Day on the lab's malleable-software projects. It is the venue where new end-user-programming primitives tend to surface first, so watch for writeups.

GitHub is locking down public stargazer and watcher data. A June 30 changelog restricts the list-stargazers and list-watchers endpoints to admins and collaborators and deprecates "repos watched by a user," narrowing what third-party tools built on public engagement data can read.

Shopify moved partner earnings to a GMV-share model. A July 7 partner post swapped subscription-only revenue share for 20% of subscription fees plus 0.1% of eligible online GMV over four years, effective for deals signed on or after August 10, tying app-partner earnings to merchant sales.

On the radar

July 20: Deno Subhosting v1 API shuts down; platforms running end-user Deno code must be on v2.
July 22: Next W3C WebAssembly Working Group meeting.
July 28: Target launch for the MCP 2026-07-28 specification; Chrome 151 reaches stable and is scheduled to remove the last flag for re-enabling Manifest V2 extensions.
August 1: Chrome Web Store policy enforcement begins.
August 10: Shopify's GMV-share partner earnings take effect.
August 31: Remaining Manifest V2 extensions scheduled for removal from the Chrome Web Store.

This Week in Extensibility is curated by Todd Schiller. Research, drafting, and fact checking are AI-assisted.