KeepChatGPT: a userscript that keeps long ChatGPT sessions from breaking

The failure mode KeepChatGPT was built around

ChatGPT sessions drop. The README lists four errors the project targets: "NetworkError when attempting to fetch resource", "Something went wrong. If this issue persists please contact us through our help center at help.openai.com.", "Conversation not found", and a content-policy warning. Each one costs the user the same thing: the reply they were waiting for, plus the work of retyping or resending the prompt.

The README frames the cost concretely. It walks through a before-and-after comparison of a single request and counts thirteen steps without the plugin against three with it. The extra steps are the recovery loop: hit the error, click resend, hit the error again, copy the prompt, reload the page, wait, reopen the conversation, paste, send, wait. The count is the author's own framing, not an independent measurement, but the shape of the problem is recognizable to anyone who has lost a long answer to a network blip.

The audience is narrow and specific. You need a browser that supports userscripts, an account on chatgpt.com, and enough patience to install Tampermonkey or Stay. It is not a library, not a proxy, and not something you run on a server. It is a patch applied to a web page you are already looking at.

How the userscript hooks into chatgpt.com

The repository is essentially one file. KeepChatGPT.user.js holds the functionality, and KeepChatGPT.dev.user.js is a loader used only during development. The README states that the dev loader pulls the current script from http://localhost:8888/KeepChatGPT.user.js, that the local server listens only on 127.0.0.1, and that it serves that one file. There is no backend, no build artifact shipped to users, and no service to keep running.

Because it is a userscript, the mechanism is DOM-level. It runs inside the chatgpt.com page, observes and modifies that page, and reacts to the errors listed above. The feature names in the README describe what that patching does: auto refresh, keep alive, data security, cancel audit, clone conversation, page cleanup, large display, tracking interception, and two features the README calls 日新月异 and 明察秋毫. The README does not document the internals of any of them, so the honest description is that the script manipulates the page and the requests it makes, and the details live in the source rather than in the docs.

That is the central architectural fact, and it is also the central risk. A userscript that runs on chatgpt.com executes with the same access the page has. The README does not document a permission model, a review process, or a threat model for the script itself. If you want to know what "data security" and "cancel audit" actually do to outgoing requests, the answer is in KeepChatGPT.user.js, and you have to read it.

Installing KeepChatGPT and getting a first session to survive

The README gives one recommended source: the raw file in the GitHub repository. It also warns that copies on the Chrome Web Store and the Microsoft Edge add-ons store are not uploaded by the author and that at least one asks users to pay. Treat the raw GitHub URL as the only install channel.

On desktop, install Tampermonkey first, then open the userscript URL. Tampermonkey should show an install page with the script name and a version; confirm the source domain is raw.githubusercontent.com before clicking install.

https://raw.githubusercontent.com/xcanwin/KeepChatGPT/main/KeepChatGPT.user.js

That URL is what the README lists under 安装渠道. Opening it in a browser with Tampermonkey installed triggers the install prompt. After installing, open https://chatgpt.com/ (the README notes the old chat.openai.com domain is also supported) and start a conversation. The README's own debugging prompt refers to a #kcg element appearing on the page and a settings menu that opens, which is how you confirm injection happened.

If you want to modify the script, the README describes a development flow. Disable the installed production script in Tampermonkey first so it does not double-inject, then install dependencies and start the dev server.

npm install
npm run dev

That runs tools/dev-server.js alongside a Jest watch process, and the loader KeepChatGPT.dev.user.js then pulls from http://localhost:8888/KeepChatGPT.user.js. Editing KeepChatGPT.user.js and refreshing the ChatGPT tab is the documented loop. The package.json shows Jest with jest-environment-jsdom and a tests directory, so there is a test harness, though the README does not describe its coverage.

Mobile installs depend on a browser you may not use

The mobile story is not a port. It is userscript support in a mobile browser, and the README names a different browser per platform. On HarmonyOS it says to use Firefox, installed from the Huawei App Gallery or Mozilla's site, then enable Tampermonkey through the add-ons manager. On iOS it says to use Safari plus an app called Stay, installed from the App Store, with usage documentation at the Stay repository.

This is the weakest part of the setup. On iOS, userscript support comes from a third-party app rather than the browser itself, so the chain is Safari, then Stay, then KeepChatGPT. Each link can break independently of the script. The README gives install steps for both platforms but no troubleshooting section for either, and it does not say what happens when the underlying browser updates its extension handling.

If you live in Chrome on Android, the README does not describe a path for you. That is not a judgement about the script, it is an absence in the documentation.

What the README does not let you verify

The feature list is long and the explanations are short. The README has sections on the keep-alive interval, on mass network errors, and on what to do if errors persist, but the features named in the summary (data security, cancel audit, tracking interception, and the two untranslated names) do not get equivalent detail here. A reader cannot tell from the README whether "cancel audit" changes what is sent to the server, suppresses something in the UI, or both.

That matters because the script runs in the page. Anything it does to requests happens with your session cookies in scope. The README does not claim the script is audited, and it does not offer a security contact. The install-channel warning about paid clones shows the author is aware of supply-chain risk, but the mitigation offered is "use the GitHub URL", which is a source-of-truth argument, not a verification mechanism.

There is also a structural fragility that no amount of documentation fixes. chatgpt.com is a moving target. A userscript that patches DOM and request behaviour is coupled to markup and endpoints the project does not control. The repository was last pushed on 2026-07-20, which is recent enough that the project is not abandoned, but the update cadence is driven by breakage on someone else's site. Expect periods where a ChatGPT front-end change breaks a feature before a fix lands.

The last limitation is the one the README states outright. If errors persist, the suggested fixes are switching networks and adjusting the keep interval. In other words, the script does not guarantee delivery. It reduces the frequency of a class of failure.

Where KeepChatGPT sits next to an API client

The obvious alternative is not another userscript. It is talking to the model through the API from your own client or script, where the transport is your code and a dropped connection is something you handle with a retry loop you wrote and can read.

The difference in approach is fundamental. KeepChatGPT keeps the web UI and patches around its failure modes from inside the page. An API client abandons the web UI entirely and takes on the work of building the interface, managing conversation state, and handling retries. You lose the ChatGPT product surface, its history, its file handling, and its account-level features. You gain a stable contract, because API endpoints change on a published schedule rather than whenever the front end is redeployed.

There is a middle option worth naming: a browser extension. Extensions install through a store, go through a review process, and declare permissions. KeepChatGPT is a userscript, which means it installs from a raw file URL with no review step. That is why it can ship fixes quickly, and it is also why the README spends a paragraph warning about paid clones. If your environment requires a reviewed install path, a userscript is the wrong tool regardless of what it does.

Choose KeepChatGPT when you want the ChatGPT web experience and the interruptions are the problem. Choose an API client when the web UI itself is the thing you are trying to get away from.

Licence, maintenance and what an upgrade actually costs

KeepChatGPT is GPL-2.0. For a userscript that you install and run in your own browser, the practical effect is that the source is available and that redistributing a modified version carries obligations. The README's own warning about clones charging users is the case where this matters: someone redistributing the script under a different arrangement is a licensing question, not just an etiquette one. This is not legal advice, and if you plan to fork or ship it inside an organisation, read the GPL-2.0 text in the LICENSE file rather than this summary.

Upgrade cost is low in mechanical terms and unpredictable in timing. There is no package to update and no migration to run. You reinstall the userscript from the raw URL, or Tampermonkey picks up the update depending on how the script header is configured. The devDependencies in package.json (concurrently, jest, jest-environment-jsdom, prettier) are for local development only and do not affect users.

The real cost is attention. Because the script tracks a third-party UI, an update can arrive because something broke. No changelog or release list is published, so you cannot read what changed before installing. The repository does carry AGENTS.md and CLAUDE.md at the top level, which suggests the project is set up for AI-assisted contribution, but that is an observation about the repository layout, not a statement about code quality.

If you pin a version, you are choosing stability over fixes for a target that moves. If you track the raw URL, you are choosing fixes over review. There is no third setting.

Editorial conclusion

Adopt it if you run long ChatGPT sessions in a desktop browser, already use Tampermonkey, and are willing to read KeepChatGPT.user.js before enabling it, since it executes inside the chatgpt.com page with access to everything that page can see. Skip it if you need a supported extension, an audited supply chain, or a stable API, because this is a page-level patch aimed at a UI that changes without notice. Verify first that the raw GitHub URL is the source you installed from, that the version banner in Tampermonkey matches what the repository shows, and that nothing else is injecting into chatgpt.com alongside it.

Frequently asked questions

Official sources

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