CWS rejection codes

Chrome Web Store rejection emails cite color-plus-element codes (“Blue Argon”, “Purple Potassium”). This page maps the classes you are most likely to meet to what triggered them and what to do.

Blue Argon: obfuscated code

Triggers: shipped code the reviewer can’t read (obfuscators, string-encrypted payloads). Minification is allowed; obfuscation is not.
Kit prevention: no obfuscation anywhere in the pipeline; standard Vite minification only.
Recovery: remove the obfuscation (often a dependency doing it), rebuild, resubmit. To protect logic, move it server-side.

Purple Potassium: undisclosed remote code

Triggers: fetching and executing JS/WASM at runtime: remote <script src>, eval of downloaded strings, script-injecting analytics SDKs.
Kit prevention: lint bans eval, new Function, and innerHTML sinks. pnpm audit:remote-code scans the built output (every JS/HTML file plus the manifest CSP) and runs in CI, so a dependency that starts shipping dynamic code fails the pipeline, not review. Remote data (gateConfig, broadcasts) is the sanctioned alternative.
Recovery: find the offender with the audit script, bundle the code locally or cut the dependency, resubmit.

Red Nickel / Red Titanium: metadata quality

Triggers: keyword-stuffed or misleading title/description, irrelevant screenshots, duplicate listings, unverified claims.
Kit prevention: none possible technically. Write the description around your single purpose, keep screenshots current, don’t enumerate competitor names.
Recovery: rewrite the named listing fields and resubmit; these are usually fast re-reviews.

Yellow Magnesium: broken functionality

Triggers: the extension doesn’t work for the reviewer: errors on a fresh install, features that require an account the reviewer doesn’t have, a paywall the reviewer can’t get past.
Kit prevention: the e2e suite runs against the real built extension, which catches fresh-install breakage like a background killed by a missing permission. The gate presets keep core functionality usable pre-wall and every wall dismissible (policy guard).
Recovery: reproduce on a fresh Chrome profile with the exact store zip. If your product requires an account or purchase, say so in the listing and provide test credentials in the review notes.

Blue Lithium: unjustified permissions

Triggers: permissions the reviewer can’t map to visible functionality: broad host patterns, tabs “just in case”, missing justifications in the privacy tab.
Kit prevention: modules declare their own permissions and pruning removes them; every entry has a written rationale (first submission §3). The kit’s one flag: narrow the demo content script’s https://*/* match before submitting.
Recovery: remove the permission or add the justification, whichever is true. Narrowing host permissions is the most common fix.

Purple Lithium / Purple Nickel: data-use disclosures

Triggers: collecting user data without matching disclosures: a privacy tab that misses data your code collects, a dead privacy-policy URL, disclosures inconsistent with Limited Use.
Kit prevention: the kit’s collection footprint is small and fully mapped, with paste-ready answers in Privacy disclosures.
Recovery: align the disclosures with reality (or the code with the disclosures), confirm the privacy-policy URL resolves, resubmit.

When a rejection doesn’t fit

Re-read the email; it names the policy section and often the specific file or listing field.
Check the current CWS troubleshooting docs for the cited code; this page covers the common classes, not the full catalog.
Appeal via the developer dashboard when you believe the rejection is a false positive; include reproduction notes.
If the listing was taken down rather than rejected, respond quickly; repeated violations escalate toward account suspension.