Submission troubleshooting

Quick fixes for the errors that stop a submission before (or during) review. For post-review rejections, see Rejection codes.

Upload and dashboard errors

symptom	fix
“An error occurred: please try again later” on upload	Almost always the zip: upload the file produced by pnpm zip from .output/, not a hand-made archive. The manifest.json must sit at the zip root, not inside a folder.
“Invalid manifest” / manifest key warnings	Never hand-edit manifest.json; it’s generated. Fix the source in wxt.config.ts and rebuild. Uploading a Firefox zip to CWS (or vice versa) also lands here: browser-specific keys like browser_specific_settings belong only in the Firefox build, which the kit’s per-browser manifest function already handles.
“Cannot submit: privacy practices incomplete”	Every permission needs a justification and every data question an answer on the Privacy tab. Work through Privacy disclosures; the submit button stays disabled until all fields are filled.
Icon errors	The manifest icon set must include 128×128. Regenerate assets rather than resizing by hand.
“Version already exists”	Bump version in wxt.config.ts (the manifest function) and rebuild; each upload needs a strictly greater version.

Stuck in review

• Pending for more than ~2 weeks: broad host permissions (https://*/* from the demo content script; narrow it), newly registered developer accounts, and first submissions all extend review. There’s no expedite button; the “contact support” form in the dashboard occasionally unsticks month-old items.
• Review keeps asking about a permission: your justification doesn’t connect the permission to user-visible functionality. Rewrite it as “user does X → extension needs Y”, or remove the permission.

The extension was approved but broken

• Test the exact store zip: unzip the file you uploaded and load it unpacked in a fresh profile. pnpm dev output and the production zip differ (env, minification).
• Check env values baked into the build: WXT_API_URL and the Firebase config are compiled in at build time; a zip built with a stale .env points at the wrong backend. Rebuild with production values and submit an update.
• The background dying on a subset of installs is usually a permission or API-availability difference; see the background guide.

Account-level problems

• Developer-account emails asking you to “verify your item” by granting OAuth access are phishing; the store never asks for that. It’s the exact lure behind the Cyberhaven compromise. Report and delete.
• Payments profile / identity-verification holds block publishing entirely until resolved in the dashboard; start that process before launch day, not on it.