chat-on-steroids: a responsible-use notice, an unsigned build, and two serial tests

The responsible-use notice is the longest section on the page

The file leads with a download button, a demo video, three claims about what the tool does, and then stops to write several hundred words about what it is not. The project calls itself an independent open-source workspace for coding and other authorised tasks with your own files and tools, states plainly that it is not intended to bypass usage limits, account restrictions or safety controls, and asks you to work within the provider's terms of use, its usage policies and its service terms, with separate links for users in the European Economic Area, Switzerland and the United Kingdom. Four rules follow. Do not use the worker, goal-tracking or session-carrying features to evade rate limits, and do not switch accounts, chats, connectors or tunnels to get around a restriction. Do not use local tools or browser control to do something the provider blocked for safety, because a local permission is not permission to override a provider refusal. Read the rules for your account before connecting and supervise the automation. And if a workflow is restricted or produces a policy warning, stop it and ask the provider. The notice also says it does not certify compliance, and that the project cannot guarantee policy compliance, continued access, or protection from a warning, a restriction or a suspension. That framing belongs in the opening paragraph of any evaluation of this tool, because it is the project's own position rather than a reviewer's.

The companion extension automates the browser and records conversations

One bullet in that notice describes the part that matters most and is least obvious. The tool connects local capabilities through the protocol layer, and its companion browser extension *also* observes and automates the ChatGPT web interface and records conversation content locally. The notice is explicit that this browser integration is not a public automation interface, and that being able to create an MCP app does not establish permission for every form of browser automation or recording. It adds that the provider's terms also restrict automated or programmatic extraction of data or output. Read together with the download buttons and the tunnelling setup in the getting-started steps, the architecture is: a desktop app with local permissions, a browser extension sitting inside the web interface, and a tunnel created for the Core connection to ChatGPT. That is three moving parts with different permission scopes, and the project's own text acknowledges the combination is what needs a usage notice rather than a feature list.

A canary build sits beside the versioned releases

The release list mixes two kinds of tag. Two are ordinary patch releases with marketing titles: v2.1.50 on 3 November about moving chats between projects, and v2.1.49 on 31 October about long chats that get through ChatGPT's limits. The third is a canary, and its title says so twice: it names the commit it was built from and adds, in parentheses, that it is not a release. So a visitor to the releases page sees a build that is newer than the latest version and is explicitly not one, which is the correct way to offer an unstable channel and an easy way to download the wrong thing if you are not reading titles. The cadence also says something: two patch releases three days apart, on a project whose package version tracks the release number exactly, which for a tool that drives another company's web interface is a fast release tempo for the surface area involved. The download buttons point at the latest release rather than at a version, so what a new visitor gets is whatever the newest version tag happens to be, not the canary.

Unsigned on two platforms and a keychain prompt after every update

The requirements section is where the operational detail is, and it is unusually candid. The project describes itself as an unsigned beta: Windows builds are not publisher-signed, macOS builds are unsigned and unnotarised, and the instruction is to verify the package against the release checksums. On macOS there is a consequence that catches people out: after each update the system asks for your login password once so the new version can open its saved keys, and until you answer that, both chats and the browser connection wait, with the app saying so. That is the price of storing credentials in the system keychain without a signed binary, and the project explains it rather than leaving people to guess why the app hangs. Linux has its own requirement, a Secret Service keyring, with a preference for the Debian package and a fallback flag for when unprivileged user namespaces are disabled. Permissions are described with the same bluntness: fresh installs enable the core capabilities and two workers, Windows additionally enables desktop permissions, and shell commands run with your normal user privileges.

Two tests are excluded from the parallel run and then run alone

The continuous integration entry point is one long command and it is worth reading end to end, because the shape of it tells you what the project is worried about. It fetches the search binary, runs a privacy verification over the public history, regenerates and compares the third-party notices, checks the native source packaging, type checks, loads the runtime to prove it can be required, then runs the test suite. The suite runs in two stages. Almost everything runs in parallel with two tests excluded, and those two then run together with the worker count forced to one. The two are named in the command, one about shutting down the local protocol server and one about desktop automation. The privacy and notices checks are the other half of the story: with a browser extension that records conversation content locally, a check on the public history and a generated notices file that must match are not ceremony.

Two third-party binaries are fetched by scripts, not installed

Two build targets download executables rather than resolving them from a registry, and both are named after what they fetch. One target fetches a search binary, which is why the pipeline starts by running it. Another fetches the tunnel client. Everything else in the pipeline is a normal check, so the sequence is deliberate: make sure the two external binaries are present and current before doing anything that might depend on them. There is also a staging target for a Firefox build of the extension, a packaging target that prepares native sources, a target that produces an icon, and a target that installs the project's own git hooks from a script in the repository. The hooks directory at the root is what that target installs, so the commit checks a contributor gets are fetched from the repository rather than configured by hand.

An Electron builder, a Nix flake and a directory named pets

The root of the repository describes a desktop application rather than a library. There is an Electron build configuration and an Electron-aware bundler configuration, a main process entry point emitted into an output directory, and a desktop bundle identifier recorded in the manifest alongside a native dependencies directory and a separate directory for the browser extension. A Nix flake and its lock file sit next to that, so there are two build and packaging systems in one repository, which is not unusual for a project that has to produce installers on three platforms and still be buildable in a reproducible environment. Two root entries are harder to place from the outside: a directory with a short, whimsical name alongside the artwork and scripts directories, and a generated third-party notices text file whose generator runs in check mode during continuous integration. The notices file is at least explained by the pipeline that verifies it.

Editorial conclusion

Judge this tool against its own notice rather than its feature list, because the notice is unusually specific about what it cannot do: it does not grant quota or access, it does not permit using local permissions to override a provider refusal, and the browser component is not a sanctioned automation surface. That makes it usable for your own files and your own authorised work inside the provider's rules and unusable as a way around a limit, and the distinction is the whole question. Before you connect anything, read the provider terms yourself rather than relying on the project's summary of them, check whether your plan and workspace can create custom MCP apps at all, and assume the recording of conversation content locally is a real cost you are accepting. If you install it, verify the package against the published checksums, because the Windows and macOS builds are unsigned and the macOS keychain prompt will appear after every update. And keep a human in the loop: the project asks for supervision and cannot protect your account.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. totec448-spec/chat-on-steroids on GitHub