CWS rejection codes

Chrome Web Store rejection emails cite color-plus-element codes (“Blue Argon”, “Purple Potassium”, …). This page maps the classes you’re most likely to meet to what actually triggered them, how the kit prevents them by construction, and what to do if one lands in your inbox anyway.

Verify before you rely on a code name

Google occasionally renames, splits, or retires these codes, and the official list lives in the CWS “Troubleshooting Chrome Web Store violations” documentation. The trigger/prevention/recovery guidance below is stable; treat the code names as best-effort and check the current CWS docs when reading a rejection email.

Code-quality and remote-code classes

Blue Argon – obfuscated or unreadable 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. If you must protect logic, move it server-side.

Purple Potassium – undisclosed remote code

• Triggers: fetching and executing JS/WASM at runtime, such as remote <script src>, eval of downloaded strings, and script-injecting analytics SDKs.
• Kit prevention: this is the class the kit is most opinionated about. Lint bans eval, new Function, implied eval, and innerHTML sinks. pnpm audit:remote-code scans the built output (every JS/HTML file plus the manifest CSP) for eval, new Function, importScripts(), document.write, string setTimeout, remote script tags, and unsafe-eval/remote-host CSP. It runs in CI on every build, 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.

Metadata classes

Red Nickel / Red Titanium – metadata quality

• Triggers: listing problems such as keyword-stuffed or misleading title/description, irrelevant screenshots, duplicate listings, and unverified claims.
• Kit prevention: nothing technical can prevent listing copy issues. Write the description around your single purpose, keep screenshots current, and don’t enumerate competitor names.
• Recovery: rewrite the listing fields named in the email and resubmit; these are usually fast re-reviews.

Functionality classes

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, dead UI). A paywall the reviewer can’t get past lands here too (bait-and-switch reads).
• Kit prevention: the e2e suite runs 12 Playwright specs 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 loaded unpacked. If your product genuinely requires an account or purchase, say so in the listing and provide test credentials in the review notes.

Permission classes

Blue Lithium – unjustified permissions

• Triggers: requesting 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; the manifest ships with the minimum for enabled features and 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.

Data-disclosure classes

Purple Lithium / Purple Nickel – data-use disclosures

• Triggers: collecting user data without matching disclosures (a privacy-practices tab that doesn’t mention data your code collects, a missing or dead privacy-policy URL, disclosures inconsistent with the Limited Use policy).
• Kit prevention: the kit’s collection footprint is small and fully mapped; see the copy-paste answers per questionnaire category in Privacy disclosures. Error reporting is consent-gated and content-free by construction.
• 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 any of these

• Re-read the email carefully; it names the specific 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.
• You can appeal via the developer dashboard when you believe the rejection is a false positive; include precise reproduction notes.
• If the listing was taken down rather than rejected, respond quickly; repeated violations escalate toward account suspension.