This Week in Extensibility: Chrome Web Store caps extensions per publisher, the blogosphere discusses LLM-generated user extensions, and YC startup Vendo launches on HN

2026-08-21T00:00:00-04:00

This week, Google made a move to curb AI slop by capping how many extensions a single publisher can list. At the same time, Jeremy Morrell's essay "Extensible Software in the age of LLMs" made the blogosphere rounds painting a future where app providers make their software "squishy".

Governance: Chrome Web Store caps how many extensions a publisher can list

Google set a per-publisher limit on how many extensions an account can list in the Chrome Web Store, defaulting to two, and started retiring the Featured badge. The August 20 announcement says each publisher now has its own limit, set by the quality and usage of its extensions, with a default of two. Publishers who already list more keep them and can request an increase from the dashboard. The same post ends the Featured badge later in 2026, closes new self-nominations right away, and changes ratings to weight recent reviews more heavily.

Why it matters: capping how many extensions one account can publish makes it harder to flood the marketplace with AI slop. Dropping the Featured badge removes a discovery signal Google says its own review standards have made less useful. The cap is individualized and existing extensions are grandfathered, so current publishers are not forced to delist anything.

Idea: apps that generate extensions for their users

Jeremy Morrell argued that web apps should become platforms for user-generated, sandboxed extensions. Because LLMs make custom code cheap to produce, Jeremy's "Extensible Software in the age of LLMs" essay contends the hard part is no longer writing code but running someone else's safely. A user would describe what they want, the app would generate an extension, and that extension would run sandboxed with narrow, explicitly granted permissions rather than open access to the app's internals. Morrell points to Cloudflare's isolated-code platform as the closest ready foundation and cites Salesforce's two-decade practice of running customers' code in isolation as precedent. The argument was picked up on Hacker News and across other blogs this week.

Vendo, an open-source project from the current Y Combinator batch, packages a version of that pattern into a drop-in layer. A software vendor adds Vendo so its own customers can build features on top of the product without source access. It turns the product's existing interface into a set of actions an assistant can take as the signed-in user, generates small custom interfaces that run in an isolated frame with no network access of their own, and routes every action through one control point that can require approval and keep an audit log. A customer can assemble live views of their data, adjust the interface by describing the change, and set up automations that span tools. Vendo launched this week as a Launch HN.

Why it matters: the pattern inverts how extensibility usually works. Instead of a vendor shipping a fixed plugin interface and waiting for developers to build on it, the customer describes a need and gets a generated, permission-scoped extension.

Infrastructure: the sandbox has to hold

The Bytecode Alliance patched a high-severity escape in Wasmtime, a runtime many products use to run untrusted code in isolation. A flaw let guest code read and write files outside the directory it was granted, using paths and symbolic links that ended in a trailing slash, rated 8.8 out of 10 in the security advisory. The fix landed across four supported release lines and went into the new major version, along with a second, lower-severity fix that closed a way for guest code to make the host allocate unlimited memory. That major version also changed the default so sandboxed code cannot open network connections unless explicitly allowed.

Why it matters: user extensions rely on the assumption untrusted code can be safely contained. A filesystem escape in a runtime that many sandboxes build on shows how hard-won that containment is. Anyone running an affected version should treat the update as urgent.

Standards: WebMCP tightens how a page hands tools to an agent

The WebMCP draft refined how a website exposes in-page actions to a user's agent. Work merged this week defined how an agent invokes a tool a page has declared, let a page pass structured input instead of plain text, and added a way to cancel a running tool while keeping in-progress work alive when a page withdraws one. WebMCP lets a site offer actions a user's own agent can call instead of scraping the page. It remains a WebML CG draft.

Why it matters: this is the interface that lets a page give a user's agent real, typed actions instead of guesswork.

Also worth knowing

WebExtensions Working Group: The group worked through how to describe the browser extension namespace in a formal interface definition and reviewed whether extensions should be able to control a browser measurement API, per draft minutes still in review. No new capability came out of the call.

Salesforce detailed its Headless Experience Layer ahead of Dreamforce. The cross-cloud layer is for building and rendering experiences across channels and bringing your own front-end apps into Salesforce's own screens, including a no-code builder.

On the radar

August 25: WebAssembly Community Group video call.
August 27: WebExtensions Community Group meeting.
September 15–17: Dreamforce, where Salesforce is targeting general availability for its Headless Experience Layer widgets, channels, and micro-frontends.

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