v10.12.0

Built on Extension.js 4.1.33.

• extension_workspace with action: "settings" points to extension_builds with action: "configure" for changing build settings. It used to say build commands change only in the console, so an agent asked to change one gave up.
• extension_release_promote and a real extension_submit say what the platform now asks of every call with a token: a promote needs a token minted by a workspace owner and a workspace owner's approval of that exact promote, and a real submission needs a workspace owner's approval of that exact submission. Both used to read as if the approval applied only while a platform setting was on. A promote refused because whoever approved it is not an owner says to request a fresh approval and have an owner approve it.
• extension_release_promote cuts a release with action: "cut": it opens a pull request in the project's source repository that bumps the manifest version by level (patch, the default, minor or major) or to an exact version, optionally armed to release to channel when merged, with releaseNotes in its body. action: "rollback" returns channel to the build it served before. Both need a workspace owner's approval of the exact act: the first call runs the platform's checks and either refuses with the reason and the next step, asking nobody (cut-refused, rollback-refused, such as a channel the project does not declare or a channel with no earlier build), or answers approval-required with the approval URL and the platform's own description of the act; the same call with the approvalId then runs it once. A rollback's approval names the build the platform resolved, so a channel whose history moved before the approval is used refuses it. Cutting a release used to need the console.
• extension_submit withdraws a submission from review with action: "cancel" (submissionId, and store, default chrome) and raises the Chrome staged rollout with action: "rollout" (deployPercentage, a whole number from 1 to 100 above the current one, which Chrome does not let be lowered again). Both need a workspace owner's approval the same way, and a submission that is not in review or a project that does not stage its Chrome release is refused before anyone is asked, saying where to look or what to turn on. action: "preflight" reads each store's readiness for browsers (the failing checks with what to fix, and the warnings, never a secret value) and writes nothing. cancel and rollout count as shipping calls in no-ship mode; preflight does not.
• extension_release_status reads three more sections: include: ["runs"] the newest release workflow runs (the last 7 days, or since a date up to 30 days back, with a token minted by a workspace owner), include: ["rollout"] the Chrome staged rollout percentage and whether it can be raised, and include: ["cut"] whether a release pull request opened now could build after merging.
• The stores section of extension_release_status keeps the platform's id on each store's latest submission, which action: "cancel" takes. It was dropped from the latest submission while the earlier ones kept it.
• extension_builds with action: "rebuild" returns the run it started: deploymentId and dispatchedAt, and runId and runUrl once the platform found the run, with follow.match naming what to compare. A rebuild keeps the build id of the build before it, so the agent reads action: "get" and matches runId, or deploymentId or a startedAt after dispatchedAt while the run has not shown up. action: "get" names the run behind the build (run: runId, runUrl, deploymentId, startedAt), and action: "list" rows carry runId, deploymentId and startedAt when the platform has them. An agent polling a rebuild by its build id used to read the earlier, finished run as this one.
• A rebuild refused because only a person may replace what a live channel serves now says to ask a person on the project to replace it from the console, where releasing the commit offers Replace and rebuild. It used to point at the Builds page, which has no such control.
• An approval request uses the platform's own description of the act when the platform writes one, and asks the agent to call again with the same arguments and the approvalId. When an approval cannot be requested or verified, the answer calls the action irreversible only when it is (a promote, a store submission, a share revoke, a rollout raise); a build settings change used to read as irreversible.
• A login refused by a platform route that is closed to logins says which tool to use instead: a promote goes through extension_release_promote, a store submission through extension_submit, and deleting a release is a person's act in the console.
• extension_builds starts a rebuild with action: "rebuild": buildId names the commit (the branch head when omitted) and buildEnv is staging (the default) or production. It dispatches a real CI run on the project's runners, counted against the workspace's build allowance, and answers at once with the commit, branch and browsers, plus the list, get and logs calls that follow the run. It never forces over artifacts a live channel serves: that refusal says which buildEnv the channel needs, and a burst or monthly cap says how many seconds the platform asks to wait.
• extension_builds changes build settings with action: "configure". Pass only what changes, such as { firefox: { buildCommand: "pnpm build" } }; the tool reads the current settings, merges the change and sends the whole set. A workspace owner approves that exact change first: the first call answers approval-required with the approval URL and the change as the platform computed it (changes), and a second call with the approvalId applies it once. A browser or field the settings do not have is refused before anything is sent, and a value the platform rejects is refused before any approval is requested.
• extension_builds adds a release channel with action: "create-channel" (channel, and optional description and color), answering with the project's channels; a channel that already exists reads as exists, not as a failure. extension_release_promote can then point it at a build.
• extension_builds is no longer marked read-only, since it now has these three actions; list, get and logs still only read, and extension_workspace and extension_release_status stay read-only.
• extension_shares shares a build the platform already made with action: "create", buildId and browser (default chrome): it downloads that build's package from the registry of the server the call names, unpacks it in a temporary folder, and uploads it the way extension_preview_web with share: true uploads a local build, with the same allowance and no approval. An archive entry that would land outside that folder refuses the whole package before anything is written. Sharing a build used to need the project checked out and built on the same machine.
• Registry reads of a private project request their access grant through the fetch in effect at the time of the read. The grant request used the fetch present when the server loaded, so a host or test that replaced fetch afterwards still sent it to the real platform.
• Logins are stored per server. A login against a local or self-hosted server (through api or EXTENSION_DEV_API_URL) no longer replaces the production login for the same <workspace>/<project>, and a production login no longer replaces the local one. Every token-scoped tool uses the login minted on the server the call targets: api, else EXTENSION_DEV_API_URL, else production. extension_auth status reports the login for that server and lists every stored login with its server; logout removes only that server's logins. Logins stored by earlier versions are read as production logins unless they recorded another server. Signing in to a local copy of a workspace used to overwrite the production logins on the machine, so the next production call sent a local token and failed.
• extension_project_create with projects answers every call within about 45 seconds: it starts no new create 20 seconds into a call, polls a pending approval for at most 15 seconds, and abandons a create request still unanswered 45 seconds into the call, marking that project unconfirmed and never sending it again. extension_project_create with one project and extension_workspace_create abandon their create request at the same point. A list of ten could hold one call past the 60 second request timeout most MCP clients apply, and the agent got "MCP error -32001: Request timed out".
• A list's provisioning grant now outlives a server restart. Until it expires it is kept in provisioning.json beside the stored logins (readable only by the user, filed under the server and a hash of the device code, never logged), so calling extension_project_create again with the same deviceCode and arguments resumes the list with no second approval. The file entry is deleted when the list finishes or the grant expires. When a timed-out call left the client on a restarted server, the device code read "expired or already redeemed" and the projects not yet created needed a fresh approval.
• extension_project_create with one project and extension_workspace_create can learn the outcome of a create that outlived the call. When the create request goes unanswered, the grant is kept in provisioning.json the same way, and calling the tool again with the same deviceCode and arguments sends the same grant again: the platform answers created from its record of the first request when that request created it, creating while it is still running, and otherwise runs the create once more and answers with that outcome, so nothing is created twice. The entry is deleted once the outcome is known. A create the platform finished after 44 seconds used to answer create-unconfirmed, and finding out whether the project existed cost the user a second approval.
• Registry reads follow a local server. When the platform base (api or EXTENSION_DEV_API_URL) is a local server, extension_release_status, extension_release_promote, extension_submit and the other tools that read build and store data read that server's registry at /api/local-registry instead of registry.extension.land. EXTENSION_DEV_REGISTRY_URL still overrides it. Against a local server the agent used to read the production registry, which refused the local login with bad-signature, so it could not see a single build of a local project.
• A login is found under every name of the server it was made on. localhost:3100, 127.0.0.1:3100 and www.extension.localhost (where a local server sends people to approve) read the same local logins, and https://extension.dev reads the same logins as https://www.extension.dev. An agent that passed the approval page's host as api used to read logged-out with the login sitting under the other name.
• A promote, store submission or share revoke that the platform refuses before asking anyone to approve it now answers as that tool's own failure (promote-failed, submit-failed, revoke-failed) with the platform's code, and says no approval was requested. extension_release_promote refused for the build's environment also says how to get a build stable accepts: stable takes production builds, and no tool starts one, so rebuild the commit for production in the console, then promote it. extension_submit no longer calls an approval spent when the platform says it refused before consuming it. A stable promote of a staging build used to ask a human to approve it, then fail with BUILD_ENV_MISMATCH and leave the approval used.
• A promote, store submission or share revoke called with an approval that was already used no longer says "nothing was executed" without qualification. It says that call executed nothing, that the call which used the approval may already have run the action, and to read the state with extension_release_status or extension_shares before requesting a fresh approval. An agent that resent a used approval read the old wording as the action never having run, and reported a promotion as missing while stable was already serving it.
• extension_release_status with include: ["stores"] also reads the platform's own record of each store's latest submission and the store run it dispatched, using the stored login for that project (never a login for another project). Each store row carries submissionRun with the run's status, conclusion and URL, the step that failed, and whether any store step ran, and a run that ended before any store step is recorded as failed with the reason that no store received the submission. A run that died before writing to the registry used to leave the read unavailable, so the agent could not learn the submission had failed, and the platform kept reading it as pending for fourteen days.
• A tool's api now picks the registry and the stored login it reads, with no environment variable needed. extension_release_status, extension_release_promote, extension_submit and extension_publish called with api: "http://localhost:3100" read that server's registry at /api/local-registry and name the project from the login made on it. Before, only EXTENSION_DEV_API_URL moved the registry, so these calls read registry.extension.land, which refused the local login with bad-signature, and a call without project named the project of the production login.
• New extension_builds reads the platform's builds of the logged-in project with its stored login. action: "list" (the default) returns recent builds, newest first, with buildId, full sha, status, build environment, channel, browsers, createdAt, conclusion and the console page; action: "get" returns one build's details and validation checks, its artifacts, an integrity summary per browser and the usage report when one was recorded; action: "logs" returns the build's CI log lines per browser, a failed browser's job failure summarized, keeping the last 200 lines of a long log and saying how many it left out. The answer is fenced as untrusted data, because log lines are written by the project's own build. An agent could see a build's status from the registry but not why it failed.
• extension_release_status accepts include: ["history"] for the platform's release history: every release (browser and channel) with its build, version, rollout, promotion run and its 5 most recent events, plus whether a build is ready to promote, which needs a token minted by a workspace owner and otherwise says so instead of failing. releaseId reads one release with up to 20 of its events.
• The stores section of extension_release_status also reads each store's configuration from the platform when the login covers the project: enabled, configured, whether its credentials are set and the names of any that are missing (never a value), its listing URL and its submission mode, plus up to 5 earlier submissions per store besides the latest. A store's credential gap used to show only as a failed submission.
• A platform that is not open yet answers extension_builds and these new reads with the same platform-held envelope as the other platform tools, naming what still works on this machine.
• New extension_workspace reads the workspace a login belongs to, with any project login of that workspace on the server the call targets; there is no workspace token. action: "info" (the default) returns the workspace (role, members, project count) and its plan: limits, what is used this month and the refusals the plan made. action: "projects" lists every project with its browsers, release channels and last build per browser, and whether this machine holds a login for it. action: "usage" returns the billing period's CI minutes, runs and cost, in total and per project. action: "settings" returns one project's general settings and its build settings per browser, read with that project's own login. workspace names another workspace; a workspace with no login on this machine is refused before any request, naming the login to make. Plan and billing changes and members stay in the console, and the answer links there. The answer is fenced as untrusted data, because names, descriptions and build commands are written by people in the workspace.
• extension_auth signs in to every project of a workspace with one approval: action: "login" with workspace and projects: "*". The approval page lists the projects the workspace has when it is opened, and the answer names each project signed in and stores its token. Only tokens for the requested workspace are stored; an answer naming a project of another workspace, or a project twice, stores nothing. A platform that does not advertise it is refused before a device code is spent. Signing in to a whole workspace used to need every project named by hand.
• A platform refusal of a login now names the next step. A login of another workspace says to log in to a project of that workspace (or all of them with projects: "*"), a login of another project says to log in to that project, a login whose approver left the workspace says to sign in again as a current member, and a read-only refusal points to the console. These used to read as a bare refused.