KeepChatGPT warns that paid copies of itself are on both browser extension stores

The installation table lists both browser stores as unofficial and says copies are sold there

There is a section of this front page that is unlike anything else in the repository, and it is the reason to read this project carefully before installing it.

There is an official channel table with one row, pointing at a raw script address served from the repository's own default branch. That row is marked as recommended.

Below it is a second table headed as fake channels, with two rows. Both official browser extension stores, one for one browser and one for another. Both are struck through in the original. Both carry the same warning: beware, this is not uploaded by the author. Someone has copied the project and is asking users to pay for it.

So the author is documenting an active impersonation and a payment scam, and doing it by linking to the places it is happening.

That is worth taking seriously rather than as a complaint. A userscript that runs with full access to the page, installed from a raw address rather than a store, is exactly the shape of thing that gets cloned and resold. And a user who searches for the extension by name will land on a store listing, not on this repository.

The consequence is concrete. Install from the raw address in the official table, check that the address is on the repository's own host, and if you find the extension in a store, assume it is not this project unless the author says so.

It is a userscript, which means the install differs on every platform it claims to support

The front page claims support for desktop systems, for mobile systems, and for a third mobile platform, and each needs a different route because the delivery mechanism is a userscript manager rather than an extension.

On a desktop the path is the conventional one: install the userscript manager from its own site, then install this script through the manager, then visit the chat site.

On the third mobile platform the front page tells you to use one particular browser, install it from that platform's own app store or the browser's official site, and then add the userscript manager by navigating through the browser's own add-ons menu to a plus button beside the manager's name.

On the phone platform the route is different again. You use the system browser, install a third-party application from the app store that provides userscript support, follow that application's own instructions, then install this script.

So the platform claim is real but the cost is three dependency chains, two of which route through an app store you may not have access to and one of which routes through a third-party application whose own instructions live in a different repository.

And because it is a userscript rather than an extension, it runs with full page access in whatever browser you use, injected at request time. There is no permission manifest to review and no store review that would look at what it does.

The consequence is that the security model here is entirely on you. You are running a script that another program fetched from the internet, with access to the page, and the store review that would normally be your backstop does not exist for this delivery route.

The keep-alive interval is a rate-limiting knob and the author's own setting is very conservative

One feature is a periodic request to keep the session alive, and the front page explains its trade-off in more detail than anything else in the document.

The interval is in seconds. The explanation is a two-way trade-off that the author states directly. A larger interval means gentler requests and a more stable account. A smaller interval means more frequent requests and fewer network errors.

Then the recommendation: at least fifty seconds. And then the author's own setting, which is nine hundred seconds, fifteen minutes.

The gap between the recommendation and the author's practice is the interesting part. The minimum recommended is a request every fifty seconds. The author runs one every fifteen minutes.

That gap tells you the author is deliberately staying well under the threshold rather than sitting at it, which is the correct posture for something that exists to avoid looking like an automated client.

So if you set this to the minimum and the extension stops the session dropping, you have also moved yourself closer to the behaviour the service is most likely to flag. The two goals are in tension and the front page does not hide it.

The consequence is to set it at the author's interval or longer if your session survives without it, and to be clear with yourself that you are reducing a rate, not fixing a bug.

The troubleshooting section lists API errors that a chat page user will never see

There is a section explaining one specific error message, and it drifts from the product this script touches into a different product entirely.

The heading names a rate-limit error expressed in requests per hour. Two of the four explanations point at the developer platform's usage page.

One says a newly registered account has no free allowance, with a solution of registering with a different email address and phone number. One says an existing account has used up its allowance, with a solution of paying for more. One attributes it to a bug in a security vendor's layer, with a solution of using a private window and clearing cookies. One says shared network infrastructure triggered risk controls, with a solution of changing network.

The advice about changing email addresses is also not something a chat-page user can act on in any meaningful sense.

The page also separately lists a set of authentication, rate limit and server error codes with short descriptions, which is the same mismatch again: a reference list of API status codes pasted into a document about a chat interface.

So the consequence is that the troubleshooting section is only partly about you. If you are on the chat page, the parts that matter are the network error and the session messages, and the numbered status codes are noise from a different context.

The development loader serves exactly one file on the loopback interface

The development setup in this repository is small and unusually well constrained, and it is worth reading because most projects of this shape are not.

There are two script files at the top level. One is the real thing that users install. The other is a loader used only for local development, and the front page is explicit that the actual functional code still lives in the first file.

The workflow has you disable the installed production copy in your userscript manager first, so the two do not both inject into the same page. Then you install dependencies, start a development server, install the loader in the manager, and edit the production-named file, which the server serves.

The constraints on that server are what make this acceptable. It listens only on the loopback address, so it is not reachable from your network. And it serves only the one file, rather than the repository directory, so there is no directory listing and nothing else to fetch.

The loader pulls the script from a fixed loopback address:

http://localhost:8888/KeepChatGPT.user.js

The project also ships a ready-made prompt you can hand to an AI agent that can drive a browser, which tells the agent to open the chat page, confirm the script loaded from the local address, check that the plugin's container element appeared, check the settings menu opens, check your specified feature works, and check the console for errors, and to produce a minimal fix rather than a rewrite.

So the consequence is that you can verify a change end to end with an agent in one step, and the local server is scoped tightly enough that running it while you work is not a new exposure.

One dependency is force-overridden to a major version the override cannot be right about

The development manifest is four packages long, which is worth noting, and it contains one entry that deserves a second look.

The four are a process runner for running two things at once, a test runner, the browser environment the test runner needs, and a formatter.

There are no runtime dependencies, which is what you would expect since the shipped artefact is a single userscript rather than a package anything installs.

Now the override. The manifest declares an override block that pins one transitive dependency to a major version above what its own package presumably requests. Overrides work by forcing a resolution regardless of what the dependent asked for, which is how you take a transitive dependency to a version its parent has not declared support for.

That is sometimes the right move and it is sometimes a security patch applied in a hurry. The manifest does not say which. There is no comment and no link to an advisory in the manifest.

So the consequence is that one dependency in the development tree is forced to js-yaml ^5.0.0, without a recorded reason. It affects your development environment rather than the script you install, since the shipped file is a userscript with no dependency resolution at install time. It is worth knowing about before you report a confusing test failure.

The feedback section is four images and a caption saying the reviews are mixed

There is a user feedback section and it contains almost no text.

The written content is three lines. That the feedback is mixed. That thanks go to the people who liked it. That the bad reports will be addressed with continued updates.

And then four images, which is where the actual feedback lives.

So the evidence people have offered about whether this works is delivered as pictures, in a repository whose licence is a copyleft licence and whose documentation is translated into at least three languages.

This is a small thing, and it is worth saying plainly because it affects how you should read the rest of the front page. The other positive claims in this document, the ones about saving steps and avoiding network errors, are demonstrated with comparison tables showing the sequence of actions with and without the script. Those tables are checkable in the sense that you can run the experiment yourself.

The feedback section is not checkable at all, because it is not words.

There is also a licence oddity worth noting. The repository is copyleft, and the licence field agrees. That is a meaningful choice for a script people inject into a page: it means anyone who modifies and redistributes this has to publish their modification under the same terms. Compare that with the paid copies the front page is warning about: the licence does not forbid charging for copies.

Editorial conclusion

This suits someone who loses a long conversation to a session timeout and wants the page to behave, and it is genuinely small: one script, four development dependencies, a test suite running in a simulated browser. The keep-alive interval is the feature to understand first, because the author's own setting of 900 seconds is far longer than the recommended minimum of 50, and the trade-off is real in both directions. Two things to be clear about. Install it from the raw script address the front page lists and nowhere else, since it says explicitly that paid copies of itself are being distributed through both browser stores. And read what the interval and the session-behaviour features do to the service's view of your account, because the front page is candid that some of its features exist to reduce the chance of a suspension.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. xcanwin/KeepChatGPT on GitHub