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-28specification; 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.