@extension.dev/mcp 10.10.7 → 10.10.9

package/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
       "name": "extension-mcp",
       "source": "./",
       "description": "MCP tools for browser extension development: scaffold from 50+ templates, run the dev server with HMR, inspect the live DOM and logs, and publish store-ready builds for Chrome, Edge, and Firefox.",
-      "version": "10.10.7",
+      "version": "10.10.9",
       "category": "development",
       "author": {
         "name": "Cezar Augusto"

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "extension-mcp",
   "description": "MCP tools for browser extension development: scaffold from 50+ templates, run the dev server with HMR, inspect the live DOM and logs, and publish store-ready builds for Chrome, Edge, and Firefox. Ships /extension, /extension-add, /extension-debug, and /extension-publish commands.",
-  "version": "10.10.7",
+  "version": "10.10.9",
   "author": {
     "name": "Cezar Augusto",
     "email": "hello@extension.dev",

package/CHANGELOG.md

@@ -1,5 +1,124 @@
 # Changelog
 
+## 10.10.9
+
+- One approval now covers several projects in one workspace
+  (BUGS_TO_FIX_MCP.md entry 27). Onboarding ten projects used to cost
+  twenty visits to extension.dev/device, one to create each project and
+  one to sign in to it, and the ten tokens then expired together and cost
+  ten more. This release is the client half and waits on the platform
+  deploy that accepts a list. The platform advertises the capability as
+  `batchOnboarding` in its login config; against a platform that does
+  not, both inputs below refuse the list before a device code is spent
+  and name the one-project call to use instead.
+- `extension_project_create` takes `projects`, a list of
+  `{ project, repo }` entries in one workspace, in place of `project` and
+  `repo`. The approval page lists every name. Each project is created by
+  its own request and its 7-day token is stored as that project's login,
+  so no `extension_auth` call follows. An entry may carry its own
+  `displayName`, `description`, `installCommand`, `buildCommand`,
+  `outputDirectory`, `browsers` and `outputDirectories`; the same inputs
+  at the top level are the default for entries that leave them out.
+- The answer has one row per project: created and logged in, created
+  with no token (the hint names the batch login to run), refused with the
+  platform's own code, unconfirmed when a request got no answer, or not
+  attempted. A refusal about one project (a name taken, a reserved slug)
+  does not stop the list. A refusal about the approval (an expired grant,
+  the hourly limit, the plan's project limit, a missing GitHub App
+  installation) stops it, and every project not reached still gets a row
+  saying so.
+- A list takes a few calls: creating a project is slow, so while
+  projects remain the answer is `status: "creating"` with the same
+  `deviceCode` to call again. The provisioning grant is held in the
+  server's memory for its 15 minutes and is never written to disk or
+  returned; if the server restarts mid-list the projects already created
+  stay created and the rest need a new approval.
+- One approval creates at most 10 projects, because the platform creates
+  at most 10 per hour for one approving account; the next 10 can start
+  in a new call once that limit allows. The cap is read from the
+  platform's login config (`createProjectsPerApproval`), with 10 as the
+  fallback when the platform states no usable number. A longer create
+  list is refused before any approval is asked for, with that reason; it
+  is never split silently.
+- `extension_auth` with `action: "login"` takes `projects`, a list of up
+  to 20 `<workspace>/<project>` names of existing projects in one
+  workspace (the platform's `loginProjectsPerApproval`), in place of
+  `project`. One approval stores one token per
+  project, which is also how a set of logins that expire together is
+  renewed. One missing project refuses the whole list and stores
+  nothing. The call that completes a batch login can take up to a
+  minute.
+- Both lists are checked before a device code is spent, by the
+  platform's own rules: one workspace, 1 to 20 names, no name twice, and
+  each project by its exact slug (lowercase letters and digits joined by
+  single dashes, at most 48 characters). The refusal names the entry.
+- A batch login or create does not change which login is the default.
+  A single login still does.
+- A server started with `--project` refuses a list that names any other
+  project, the same refusal a single call gets, and takes a list of the
+  pinned project alone. A list on `logout` or `status` is refused rather
+  than ignored.
+- `extension_project_create` no longer lists `project` and `repo` as
+  required in its schema, since a list replaces them. A call with
+  neither form is still refused, by the tool.
+- `extension_publish` with `project` now describes the project it was
+  called for (BUGS_TO_FIX_MCP.md entry 44). The token was already picked
+  by `project`, but `registryUrl`, and the build index behind a missing
+  `buildSha`, `version` or `builtAt`, came from the most recent login, so
+  with several logins stored a publish for one project could return
+  another project's registry address and fill its build details from
+  another project's builds. The same slip is fixed in
+  `extension_release_promote` (the builds page, the channel list and the
+  public URLs it returns) and in the `extension_submit` dry run (the
+  console page it names). `extension_shares` and `extension_preview_web`
+  were checked and did not have it.
+- A private project's registry data is read with the login stored for
+  that project. It used to be asked with the most recent login, which
+  gave up on a mismatch and reported the builds as missing.
+- `extension_release_status` reads a `project` given as
+  `<workspace>/<project>`, the form every other tool takes. It used to
+  join the pair to the active login's workspace and ask the registry for
+  an address that names no project, which is also what a server started
+  with `--project` sent on every call.
+
+## 10.10.8
+
+- On Firefox, `extension_eval` now reads an extension whose content
+  security policy forbids eval, which is every MV3 extension page
+  (BUGS_TO_FIX_MCP.md entry 20). Extension.js 4.1.31 evaluates such a
+  document over the debugger protocol, but the wrapper this server put
+  around a popup, options, sidebar or override-page expression called
+  eval itself, so those contexts still answered "blocked by CSP" on an
+  engine that could read them. A refused surface is now asked again with
+  the bare expression, which the engine takes over the protocol and
+  awaits there. A project pinned below 4.1.31 keeps the refusal, and its
+  hint now names that floor.
+- `extension_eval` with `context: "page"` and a `moz-extension://` url
+  reaches a page the manifest declares as no surface (`pages/*`), through
+  the console actor of the tab showing it. It used to answer
+  `E_NO_SURFACE_DOCUMENT`. Open the page with `extension_open` first; a
+  page no tab shows answers `E_NO_MATCHING_TARGET`.
+- `extension_dom_snapshot` on a `moz-extension://` url reads the page the
+  same way when Firefox refuses the injection with "Missing host
+  permission for the tab", and returns the engine's own snapshot fields.
+- `extension_eval` with `context: "page"` on a site whose policy forbids
+  eval now works on an MV3 Firefox build, over the debugger protocol,
+  when `url` names the tab. An MV2 build keeps its `tabs.executeScript`
+  route, which had gone dead on Extension.js 4.1.31 because that engine
+  renamed the refusal to `E_CSP_BLOCKS_EVAL`; both spellings are read now.
+- The protocol takes one expression. A statement list sent to a
+  policy-locked Firefox document answers `E_BAD_REQUEST` with the way to
+  wrap it, where the background used to answer a control-channel error
+  carrying "SyntaxError: expected expression".
+- Still refused, by name: a string evaluated in the content-script world
+  of an extension whose policy forbids eval. Use `context: "page"` or
+  `extension_dom_snapshot` there.
+
+- `extension_submit` and `extension_store_status` link to the console's
+  Submissions tab at `/<workspace>/<project>/submissions`, where the page
+  moved; the old `/stores` address still redirects. `@extension.dev/urls`
+  moves to `^0.8.2`, which carries the new paths.
+
 ## 10.10.7
 
 - A share revoke now waits for a person by default, like a real store

package/README.md

@@ -217,9 +217,9 @@ cp node_modules/@extension.dev/mcp/claude/commands/*.md ~/my-extension/.claude/c
 | act | `extension_reload` | Reload extension or tab |
 | act | `extension_open` | Open a surface (popup, options, sidebar, devtools panel, override pages) / trigger `action`, `command` |
 | browsers | `extension_browsers` | Detect, list, install, and uninstall browsers |
-| platform | `extension_auth` | Device login at extension.dev, plus login status and logout |
+| platform | `extension_auth` | Device login at extension.dev for one project or a list of them, plus login status and logout |
 | platform | `extension_workspace_create` | Create an extension.dev workspace, headless, via device approval; the approver becomes its owner |
-| platform | `extension_project_create` | Create the extension.dev project for a built extension, headless, via device approval |
+| platform | `extension_project_create` | Create the extension.dev project for a built extension, or several under one approval, headless, via device approval |
 | platform | `extension_preview_web` | Render a build in the web emulator, and share it as a link |
 | platform | `extension_shares` | List every link you have shared, and revoke one permanently |
 | platform | `extension_publish` | Publish a shareable preview to extension.dev |
@@ -314,6 +314,8 @@ That is a different job from shipping. Use `share` for the build you are holding
 
 The platform tools connect agents to [extension.dev](https://extension.dev): `extension_auth` runs extension.dev's own device flow (you approve the code at [extension.dev/device](https://extension.dev/device), and GitHub is federated server-side, so no GitHub token ever reaches your machine) and stores a project-scoped token locally (never returned to the agent), `extension_publish` turns a build your project has already published into a shareable URL, and `extension_release_promote` promotes a tested build to a release channel from CI or an agent session, no browser required. `extension_submit` submits a built extension to the Chrome Web Store, Edge Add-ons, and Firefox AMO through extension.dev, which holds your store credentials and dispatches the release from your project's mirror CI, it defaults to a dry run and store credentials are never tool arguments. Safari and the App Store are one paid lane on the platform, so a free workspace is refused there and the other three stores are unaffected. The two verbs are not interchangeable: `extension_publish` pushes to the extension.dev platform, `extension_submit` sends the build into a store's review queue, which is irreversible. After a real submission, `extension_release_status` reads the recorded outcome, per-store credential health, and review state from the project's public registry, so agents and CI can answer "was it approved?" without a console visit. Access tokens live at most 7 days; CI pipelines re-mint them from the console's Access tokens page.
 
+Onboarding several extensions at once costs one approval, not two per project. `extension_project_create` takes `projects`, a list of `{ project, repo }` entries in one workspace, in place of `project` and `repo`: the approval page at extension.dev/device lists every name, each project is created by its own request, and each one's 7-day token is stored as that project's login. `extension_auth` with `action: "login"` takes `projects`, a list of `<workspace>/<project>` names of existing projects, and stores one token per project, which is also how logins that expire together are renewed. Both lists are checked before a device code is spent: one workspace, 1 to 20 names, each by its exact slug (lowercase letters and digits joined by single dashes, at most 48 characters), none twice. A create list is capped at 10, because the platform creates at most 10 projects per hour for one approving account; a longer one is refused with that reason rather than split, and the next 10 can start in a new call once that limit allows. The platform states both caps, and that it takes a list at all, in its login config; a list sent to a platform that does not advertise it is refused before a device code is spent. Creating takes a few calls: while projects remain the answer is `status: "creating"` with the same `deviceCode` to call again, and the answer always carries one row per project, so a refusal on one never hides the others. A server pinned with `--project` refuses a list that names any other project.
+
 ## The extension.dev stack
 
 | Package | Use it to |