Todd Schiller - Chrome

This Week in Extensibility: six vendors standardize agent-plugin bundles, Mozilla stays neutral on WebMCP, Atlassian opens Rovo to Forge apps

2026-08-07T00:00:00-04:00

The theme this week was a split between packaging and trust. Six rival agent vendors agreed on how to bundle plugins while deliberately leaving security out of scope, Chrome began enforcing store rules that police what an extension may do, and the browser engines filed divergent positions on the API that would let a page hand tools to a user's agent. The packaging layer is converging faster than the trust layer underneath it.

Packaging: six vendors standardize agent-plugin bundles

Amazon, Cursor's maker Anysphere, GitHub, Microsoft, OpenAI, and Vercel published Agent Plugins 1.0.0, a vendor-neutral format for packaging agent extensions. The specification, announced August 6 in a joint post from Vercel, defines a bundle of a plugin.json manifest, a skills/ folder, and an mcp.json file so one plugin installs across ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code rather than being repackaged per client. It is labeled a Working Draft, and it carries no permission model, sandboxing, code signing, or secrets mechanism, with each of those deferred to future work; every client keeps its own trust and marketplace decisions.

Why it matters: the same customization, a set of Skills and MCP tools, becomes portable across the major agent clients instead of tied to one vendor's format, so a user is not re-installing per platform. The vendors standardized the bundle while leaving the permission and signing model to each client, so the portability is real and the safety guarantees are not yet part of the standard.

Standards: Mozilla files a neutral position on WebMCP

Mozilla recorded a neutral position on WebMCP, leaving the three browser engines split. WebMCP lets a website expose in-page tools that a user's own agent can call. Mozilla's August 5 position is neutral, while Apple's WebKit team has filed an oppose position citing privacy, security, venue, and API-design concerns, and Google and Microsoft are authoring the proposal. WebMCP remains a Web Machine Learning Community Group draft shipping only as a Chrome origin trial, so there is no cross-vendor agreement and no stable implementation.

Why it matters: the API that would let any site offer tools to a user's agent now has explicit, divergent positions from every engine, which points to a contested track rather than one converging toward shared support. It does not change that the only running implementation is a single browser's origin trial.

Marketplaces: Chrome Web Store begins enforcing its updated policies

Chrome Web Store policy enforcement began August 1 across its extension ecosystem. Four policies published July 1 took effect: a Limited Use rule narrowing data collection to what is strictly necessary for an extension's single disclosed purpose, a duty to notify users of post-install changes to data handling, a Regulated Goods ban on extensions enabling real-money prediction-market transactions, and a Malicious Products clause that bans extensions built to circumvent an AI service's safety guardrails or usage restrictions. Non-compliant extensions face enforcement after the date.

Why it matters: a marketplace of this reach setting a hard rule against extensions that defeat AI guardrails draws a governance line at the store level, where the platform, not each AI service, decides that circumvention tooling is not distributable.

Platforms: Atlassian opens Rovo to Forge apps and extends its Connect deadline

Atlassian shipped an Early Access Rovo MCP Module that lets Forge apps expose their actions as tools inside Rovo Studio. The August 3 changelog entry lets a Forge app publish its actions as callable tools for makers building custom agents in Rovo, extending the app platform into Atlassian's agent framework rather than shipping a single agent. In the same window Atlassian extended Connect end-of-support to January 31, 2027, moving the deadline out of the year-end crunch, and began direct outreach to vendors still running Connect or hybrid apps so they migrate to Forge.

Why it matters: it gives Marketplace developers a supported path to surface their apps as tools inside Atlassian's agents, while the Connect deadline sets the date by which the whole ecosystem must be on Forge to reach that surface at all.

Also worth knowing

Merge added a governed catalog of MCP connectors to its Agent Handler. A July 31 changelog lets a company embedding Merge browse and enable hundreds of generic MCP connectors alongside Merge-built ones on the same authentication, access-control, and governance layer, and adds an AI Guardrails experience with PII detection and a live rule tester.

Wasmtime patched two sandbox-integrity advisories across four release lines. The Bytecode Alliance shipped v47.0.3 and matching v46, v36, and v24 releases on July 31 to fix two low-severity advisories where engine type indices could be confused and where traps during bulk operations could corrupt VM state. Backporting to the v24 long-term line reflects Wasmtime's use as production plugin-isolation infrastructure.

CopilotKit released a Channels SDK for running AG-UI agents in chat surfaces. The August 4 SDK runs one AG-UI agent across Slack, Teams, and other chat platforms with generative UI, human-in-the-loop approvals, and cross-channel memory. It is a developer library for shipping agents rather than a customization surface handed to end users.

On the radar

August 13–14: MCP Dev Summit in Seoul, co-located with Open Source Summit Korea.
September 1: Atlassian Forge Object Store currentVersion field deprecation takes effect.
September 30: Atlassian sunsets the confluence:fullPage and jira:fullPage modules in favor of a unified global:fullPage.
January 31, 2027: Atlassian Connect end-of-support; Marketplace and custom apps must be on Forge.

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

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.

Did Google sneak a local LLM model into Chrome?

2026-05-26T00:00:00-04:00

There's a lot of FUD around Chrome's new Local AI models. Jason Calacanis on the All-in Podcast got it wrong: Chrome didn't sneak in a local LLM model; it was in their official Early Preview Program for months.

The local LLM shipped in 148 is their general Prompt API powered by Gemini Nano. Smaller, task-specific models for language detection, translation, and rewriting have been available since Chrome 138 (June 2025), a long time at AI pace!

Local LLMs distributed with the browser are critical to a future where users control their browsing experience while ensuring privacy. Consumers cannot be expected to figure out how to connect their web tools and extensions to Ollama or LM Studio. And enterprises cannot be expected to deploy local LLM servers to desktops.

There are still valid concerns about model lock-in. That's because AI models ( especially small models) can behave differently for the same prompt. But, from what I've seen, the Chrome team has been, by and large, responsible in how they've rolled out the technology. For example, the public API shipped in 148 does not expose model-specific parameters.

Local LLMs enable a range of productivity/compliance use cases, especially for regulated industries handling financial and health data. But since this is LinkedIn, here's a fun one instead: using PixieBrix + Local AI to customize your LinkedIn feed and hide self-promotional, snarky, or sarcastic posts. The question is -- will anything be left on my feed? 😆