Control Panel for Twitter: a browser extension that keeps rewriting itself around X

A support repository that also holds the extension source

The README leads with a notice that shapes how to read everything else: this is the support repository for Control Panel for Twitter, and installation links, screenshots, information about the extension and FAQs live on the project website instead. If you came here looking for a download, the answer is that you are in the wrong place by design.

The source is nevertheless here, and it is plain to read once you know the layout. Three top level scripts carry the weight: `content.js` for the injected page logic, `background.js` for the extension background context, and `script.js` sitting alongside them. Options are a separate small app with `options.html`, `options.js` and `options.css`. A `types.d.ts` and `jsconfig.json` give the project TypeScript definitions for what is otherwise plain JavaScript, which is the pattern used to get editor completion without migrating the codebase.

Two details are easy to miss and both signal care. There is a `NOTICE` file alongside the MIT `LICENSE`, which is the attribution convention for bundled third party assets. And there is a `PRIVACY_POLICY.md` in the repository root, not only on a website, so the privacy claims travel with the code. Given that this kind of extension reads and rewrites a social feed, both files are worth reading before you install it.

Two manifests, because two extension platforms still coexist

The tree contains `manifest.mv2.json` and `manifest.mv3.json`, and the build system produces both. This is the single most informative thing about the project's engineering. Manifest V3 replaced V2 in Chrome and has been rolled out across the other stores since, but the extension still ships a V2 build, which means the Firefox path, and the Android build that runs through Firefox for Android, are still served a V2 manifest.

The `package.json` scripts make the build matrix explicit, with a separate target for each browser:

"build": "node ./scripts/build.js",
"build-mv2": "node ./scripts/build.js 2",
"build-mv3": "node ./scripts/build.js 3",

And for running it against each target during development:

"firefox": "web-ext run --start-url https://twitter.com",
"chrome": "web-ext run --target chromium --start-url https://twitter.com",

There is a Firefox for Android script too, using `web-ext run -t firefox-android --firefox-apk org.mozilla.fenix`, and separate Edge scripts that point `web-ext` at a Chromium binary path, with distinct ones for Windows and macOS because the executable lives somewhere different in each. A `scripts/` directory holds the build, copy and release tooling, and each browser script has a `pre` hook that regenerates the browser action icon and copies the right manifest into place as `manifest.json`.

What the changelog reveals about working against a moving target

The release notes are the most revealing document in the repository, because they describe the extension as a series of adjustments to a platform that keeps rearranging itself. Version 4.24.2, published 2026-09-22, contains three fixes: skip the new Media button menu when Hide Grok is enabled, process the current page when the extension was disabled at load and then enabled, and stop running on the `/account/access` page.

Version 4.24.1 added an option to revert emoji to Twemoji, enabled by default, and fixed the layout of restored external link headlines. Version 4.24.0 is the longest of the three and reads like a bug report filed against Twitter. It added options to revert media carousel and profile tab changes using X's own feature flags, added support for the new History page's tabbed timelines, hid a new Grok upsell in the desktop sidebar, replaced the option to hide Bookmarks with an option to hide the new History page, and fixed hiding the Edit Image button in timeline Tweets.

Two lines from that release explain the whole project better than the feature list does. One moved the "Tweak new layout" option into an Experiments section, with the note that the site seems to have given up on it. Another removed the option to redirect to twitter.com, because logging in via twitter.com now sets a cookie for x.com and the redirect had become pointless.

That pattern, an option added, then renamed or removed as the site changes underneath, is the true cost model of this project. Six releases in three months is not churn for its own sake.

Distribution means five store reviews, not one

Each release page carries an Availability section headed with a fraction, and the most recent one reads five out of five. A comment in the release notes explains why: new versions have to be reviewed and approved for each browser before they are available to install or upgrade to. The version available list shows badges for Safari on macOS, Safari on iOS, and Firefox with Firefox for Android, alongside the store listings for the Chromium based browsers.

The Safari entries are the interesting ones, because Safari extensions need a wrapping application on Apple platforms rather than a plain add on install. The tree has a dedicated `safari/` directory and the repository topics include `safari-extension`, which is consistent with shipping a container app. The release notes point at an App Store listing covering both the macOS and iOS platforms.

For a user this means one thing that is easy to get wrong: the version in your browser store may be older than the newest tag in the repository, simply because one store has approved it and another has not. The author also points at an account on Twitter for extension news and, more recently, a Bluesky account, so following release announcements is the practical way to know a new version is actually available to you.

Reporting a bug well, and what the repository leaves out

The support section is short and specific. It asks for a new GitHub issue with three things included: the version of the extension, the browser and operating system, and relevant URLs and screenshots. It also gives two routes for people without a GitHub account, a feedback form on the project website and an email address.

That request for the version number is the clue to the project's shape. With 2,627 stars and 328 open issues, this is a popular extension with a large and largely unanswered issue queue, which is the normal state of affairs for a volunteer maintained project that is doing real triage work on a platform that changes constantly. The open issue count is high enough that it should inform how you use it: it works, and the maintainer ships fixes on a clear cadence, but expecting a conversation in the tracker is unrealistic.

What the repository does not contain is the documentation. There is no feature list, no options reference, no screenshots and no FAQ, by explicit design, because all of that is on the website. The `_locales/` directory tells you the extension is at least partially translated, and the `promo/` directory holds store listing assets. So the repository is where the code, the build system and the changelog live, and the website is where you decide whether a given feature exists.

Editorial conclusion

This extension is best understood as a patch set rather than a feature, and its value is measured in how much of Twitter you have managed to switch off. The repository makes the trade explicit by shipping separate Manifest V2 and V3 builds, a per browser run script, and a Safari directory, so the project is a real multi target extension rather than a script you paste into a console. The repository you are reading is the support and source repo, with installation, screenshots and FAQs on the project website. Read the releases page before pinning a version, because named options do get renamed or replaced when the underlying site changes.

Frequently asked questions

Official sources

1. insin/control-panel-for-twitter on GitHub
2. License: MIT
3. Project website
4. README
5. Releases