extension_submit_check
Read a store submission and ask for an approval through extension_submit's own handler, under a read-only hint.
Quick start
Is my extension ready for the Chrome Web Store?
How the agent uses it
preflight, status and submit with dryRun true (the default) dispatch nothing. Every first call with no approvalId that only asks a workspace owner to approve an exact act (approval-required, value.approvalUrl) comes here and executes nothing: submit with dryRun:false, publish, cancel, rollout, release, a derived sync-listing, a public configure-store. The call carrying the approvalId, and a plain sync-listing or configure-store, run through extension_submit; this tool refuses them.
Reference
| Group | platform, on with --features=local,platform (private alpha) |
| Tier | Platform |
| Needs | the server started with --features=local,platform, and a login; never sends: asking for the approval of a submit, publish, cancel, rollout, release, derived sync-listing or public configure-store executes nothing, and the approved call runs through extension_submit |
| Read only | yes |
| Destructive | no |
| Idempotent | yes |
| Reaches the open web | yes |
Inputs
| Input | Type | Required | Default | What it does |
|---|---|---|---|---|
action | "preflight" | "status" | "submit" | "publish" | "review" | "cancel" | "rollout" | "release" | "sync-listing" | "configure-store" | "connect" | no | "submit" | preflight, status, or submit (the default): a dry run unless dryRun is false, which only asks for the owner's approval; publish, review, cancel, rollout, release, sync-listing and configure-store only ask for the approval of that act, with the same arguments extension_submit takes for it. Each answers as extension_submit answers the same call. |
project | string | no | Which stored login to use, as '<workspace>/<project>' (or a project slug that matches one login), when extension_auth has signed in to more than one project on this machine. Omitted, the login this server resolved first is used, after EXTENSION_DEV_TOKEN when that is set, and a login made elsewhere on this machine does not move it. Named, it outranks EXTENSION_DEV_TOKEN. extension_auth (action: status) lists the stored logins. | |
browsers | array of "chrome" | "firefox" | "edge" | "safari" | no | Stores to act on: chrome, firefox, edge, safari. A submit takes several; so does publish (chrome, edge, safari, with buildSha) and sync-listing, under one approval per version with one line per store, and the answer's value.lines says per store whether its line ran, was queued, given back or left out. | |
buildSha | string | no | The built commit SHA to submit. It needs a completed build in the project's build index; an unknown sha is rejected. | |
version | string | no | Version label for the submission record (optional). Left out, the platform reads the built manifest's version from the build's own record, and each submissions[] row answers version as the store version it sent (<manifest version>.<build number>, the same number extension_release_status reads) beside storeVersion; the sha appears as the version only when the build record cannot be read. A submit takes no channel and buildSha names the build: a submission is the stable release of that build for that store, and the channel a submissions[] row carries is the one that pins the build on the registry, when one does, never an input. | |
dryRun | boolean | no | true | true (the default) rehearses and dispatches nothing: the platform verifies the token and project, finds the store workflow, reads the build from its index and each store's connection record, and answers one value.verdict (ready, not-checked, platform-refused, or the blocking state store-not-connected, store-connection-failed, store-item-not-linked, store-not-configured or store-unhealthy) with value.nextStep and value.trackUrl; it does not run the owner gate, the approval, the build quota, the dispatch pause or the submission-mode check, which the real run does first. false submits: it reads the store connection and refuses before any approval when the store is not ready, needs a token issued by a workspace owner and that owner's approval of this exact submission, dispatches the store workflow, and a Chrome or Edge upload from here stops at the draft under the default modes (Chrome draft-until-public, Edge draft), while a mode saved in the console store settings is honored whoever saved it: Chrome public or staged and Edge review send the upload on to review, and the approval says so (preflight answers the saved mode under value.stores.<store>.submissionMode, extension_release_status under config.submissionMode). Store credentials are never arguments, and no local file is uploaded. |
projectPath | string | no | Path to the extension project root. A submit and a preflight read it only for the local STORE.md advisory, and nothing local is uploaded; without it a submit's check falls back to the server's working directory. sync-listing requires it and sends the listing text parsed from its STORE.md, the 128 px icon of the build the store receives (the platform build of its checked out commit, else its dist when current, else its source icon) and the screenshots named, nothing else. | |
screenshots | array of string | no | With sync-listing, the PNG screenshots inside projectPath (for example written by extension_screenshot) to set as the listing's screenshots. Each store takes its own count and sizes, and a file off its store's sizes or a count over its cap is refused here before any approval: Chrome 1 to 5 at 1280x800 or 640x400; Edge up to 6 at 1280x800 or 640x480; Safari 1 to 10 macOS screenshots at exactly 1280x800, 1440x900, 2560x1600 or 2880x1800, showing the extension running in Safari; Firefox any size, optional. | |
useBuild | string | no | With sync-listing, the sha of a completed platform build to take each store's 128 px icon from, in place of the build of the commit projectPath has checked out; extension_builds lists the shas, and an unknown or unfinished one is refused before anything is sent. | |
detail | boolean | array | no | With preflight: what to answer in full. Omitted, each store answers its failing and warning checks whole, and its requirements and bringList list only the rows not on file (an unknown row as its id, label, status and dashboard tab), counting the rest in onFile, so a four-store preflight stays a few KB. true answers every row with its format, how and docs; a list of stores and requirement ids, such as ["chrome", "safari.subtitle"], answers only those in full. | |
api | string | no | Platform base URL (default EXTENSION_DEV_API_URL, else https://www.extension.dev) | |
store | "chrome" | "firefox" | "edge" | "safari" | no | With cancel or rollout, the store (default chrome, the one store that supports both); with release, safari (the default and the only store with a manual release); with configure-store, the store whose settings change (required). | |
storeSettings | object | no | With configure-store, only the settings that change for store: enabled (boolean: whether the platform submits to this store at all), submissionMode (the store's own mode id: chrome draft-until-public, draft, public or staged; edge draft or review; firefox unlisted or listed; safari draft or review; dry-run on any store rehearses without uploading; chrome public or staged, edge review and firefox listed send the next upload to a review that publishes it, and safari review lets the submit's one version approval also cover the publish act that sends the TestFlight build to App Review while putting it on sale stays its own approval unless STORE.md states - Release: after approval under ## Safari, so these answer approval-required first, and every other mode is a plain owner write), the store's listing id (chromeItemId, edgeProductId, firefoxAddonGuid or appStoreId, a plain write checked in the store's own terms), for Safari bundleId (the project's reverse-DNS bundle identifier, a plain write), for Chrome publisherId (the token after /devconsole/ in the item's dashboard address, a plain owner write) or storeUrl (that dashboard address, which saves the publisher id and the item id together), for Edge firstSubmitted (true once the product was submitted once in Partner Center, a plain owner write) and storeUrl (the Edge Add-ons listing URL carrying the crx id, a plain owner write), and for Firefox sourceArchive (repository attaches the source repository at the built commit, which Mozilla requires for a bundled build; none sends nothing) and releaseChannel (listed or unlisted, the same write as submissionMode). Never a credential or another store's URL: those stay in the console. The Safari release mode (manual, or after approval) is no store setting either: it is the - Release: line under ## Safari in STORE.md, which sync-listing carries to App Store Connect. | |
submissionId | string | no | With cancel, the platform's id of the submission to withdraw; with publish, the draft to send to review (default the newest draft of that store); with release, the Safari submission whose App Store version to release (default the one Apple holds in PENDING_DEVELOPER_RELEASE). From extension_release_status include:['stores']. | |
buildNumber | integer | no | With publish or release and browsers ['safari'], the TestFlight build number Apple shows (extension_release_status include:['stores'] lists each Safari submission's build) to send to App Review, in place of submissionId; omitted, the newest TestFlight build on record is sent. A number no submission carries answers publish-refused with value.knownBuildNumbers, a withdrawn or lower build than a newer draft answers SAFARI_NEWER_BUILD, and the approval names the build: 'Send App Store version 0.2.0 with TestFlight build 13 to Apple's App Review'. | |
deployPercentage | number | no | With rollout, the share of users to raise the staged rollout to: a whole number from 1 to 100, above the current one. | |
connectSession | string | no | With connect, the session id the first connect answer named in value.connectSession, to wait on the same page instead of opening a new one; pair it with waitSeconds. The session is bound to the project that opened it, so on a machine with several logins the wait answers for that project without project or projectPath; the first answer's hint also names project in the call it hands out. | |
replace | boolean | no | With connect, true opens the connect page even when the store already has a connection that passes its check, so the key the person saves there replaces the working one. Only when the person asked to replace the key. | |
waitSeconds | number | no | How long, in seconds, this call waits for the platform's own record to show the act's result before answering: 0 to 600, default 180. 0 reads the record once and answers at once. When the bound passes first, the status is <act>-dispatched with value.outcome.recorded false, and the hint names the read that confirms it later. A read the platform does not answer (a timeout, a refused connection, a 429 or a 5xx) is retried after retryAfterSeconds while the bound lasts, and only when the bound is spent on such reads does value.outcome.readProblem name them with their count. With approvalId, a call that names waitSeconds also waits for an approval nobody has decided yet: it polls the approval every retryAfterSeconds up to the bound, and once a person approves it goes straight on to the act and the record wait in the same call, with what is left of the bound. |
When it fails
- The tool is missing from the client's list. Start the server with
--features=local,platform; see Platform tools. - The platform refuses the call. Log in first with
extension_auth. - The answer reads
status: "platform-held". extension.dev is not open to the public yet, so nothing ran on its machines. Creating, running and building an extension still work on your machine; see Use the platform from your agent. - The answer depends on the network. This tool reaches the open web, so a refusal can be the network, not the project.
Next
- MCP server: install, the two groups and the session gates
- Install in your client
extension_approvals: Read or revoke one approval a workspace owner was asked for on extension.dev.extension_auth: Sign this machine in to extension.dev, report that login, or clear it: action status (the default), login and logout.extension_builds: Read, download, rebuild and configure the platform's builds of the logged-in project on extension.dev: action list (the default), get, logs, download, recheck, rebuild, configur...extension_preview_web: Preview a build in the web emulator and share it as a quick link anyone can open, with no install, sign-in or dev server.extension_project_create: Create an extension.dev project for an extension that has none yet, without opening the console: right after extension_create and extension_build, once the source is pushed to a...extension_publish: Publish a build of the logged-in project on extension.dev and answer the link to send testers, which opens a page with a download and a run command for each browser.extension_release_promote: Release a build to a channel.extension_release_status: Read where a project stands on extension.dev from the public registry (registry.extension.land): its release channels with each channel's audience and recent builds (include:'re...extension_shares: List, create and revoke the emulator preview links that give a tester one build and its zip (the uploads this login has shared, the same links extension_preview_web share:true h...extension_submit: Submit a built extension to a store through extension.dev, which holds the store credentials and uploads (Chrome Web Store, Firefox AMO, Edge Add-ons, App Store for Safari), and...extension_workspace: Read the extension.dev workspace a stored login belongs to, and change one project's settings.extension_workspace_create: Create an extension.dev workspace that does not exist yet, without opening the console.