You submitted your extension, waited days for review, and got back a rejection
with a violation called "Purple Potassium." Your extension looks fine to you, so
what does it even mean? Here is what it is, why it happens, and how to catch it
before you ever hit submit.

What "Purple Potassium" actually means

"Purple Potassium" is Google's internal tag for excessive or unused
permissions. Your manifest requests access to something your code does not
actually use, and the reviewer flags it. It is one of the most common reasons a
Chrome extension gets rejected, and it is frustrating precisely because the
extension works fine in testing. Review is checking something testing never does:
whether every permission you ask for is justified by your code.

The usual causes

1. API permissions you declared but never call. You added tabs,
bookmarks, or cookies to your manifest at some point, but there is no
chrome.bookmarks.* call anywhere in your code.

2. Host access that is too broad. You requested <all_urls> when your
extension only touches one site:

// Flagged
"host_permissions": ["<all_urls>"]

// Better
"host_permissions": ["https://*.example.com/*"]

1. Leftover permissions after removing a feature. You shipped a feature that
   needed downloads, later removed the feature, and forgot to remove the
   permission.

2. The tabs misunderstanding. The tabs permission does not grant access
   to the tabs API. Basic methods like chrome.tabs.create() work without it. It
   only grants four sensitive Tab properties: url, pendingUrl, title, and
   favIconUrl. If you declare tabs but never read those, it counts as unused.

How to fix it by hand

1. List everything in permissions, optional_permissions, and host_permissions.
2. For each one, search your code for the matching chrome. call.
3. Remove any permission with no usage.
4. Narrow and other broad patterns to the specific hosts you need.
5. In your reviewer notes, write one plain sentence per sensitive permission explaining why you need it. Reviewers often lack context, and this prevents a lot of back and forth.

This works, but it is tedious and easy to get wrong, especially the tabs and
host-permission rules.

The faster way: lint it before you submit

I built a small CLI that does this check automatically. Point it at your unpacked
extension directory:

npx tabsmith-lint ./my-extension

It statically reads your code, builds an inventory of which chrome.* APIs you
actually call, and compares that to what your manifest declares. Then it reports
the likely rejection causes with the matching violation IDs, for example:

[fix] PERM001 Permission "bookmarks" appears unused (Purple Potassium)
manifest.json:8
No chrome.bookmarks/browser.bookmarks usage found.
Fix: remove "bookmarks" unless it is required by code not in this package.

It also flags broad host access, remote code, and missing or wrong-case file
references. You get a pass / needs fixes / high rejection risk verdict and
exit codes, so you can run it in CI.

One important caveat

This is static analysis, not magic. A linter that tells you to remove a
permission you actually use is worse than no linter, so the unused-permission
rule is deliberately conservative: it ships as a warning, not a hard error, and
it lowers its confidence when it sees dynamic access like chrome[name]. It is
also honest about its limits. Deeply bundled extensions can still hide usage from
it, which is documented.

If you want to verify the accuracy yourself rather than take my word for it, the
project ships an open benchmark of hand-labeled real extensions and a scorer you
can run with npm run score.

Bottom line

The Purple Potassium rejection comes down to one rule: request the narrowest
permissions your code actually uses, and nothing more. Audit your manifest
against your code before every submission. Doing it by hand works; running a
linter is faster and catches the cases that are easy to miss.

Tool is MIT and open source: https://github.com/rsub122/tabsmith-lint