Chat On Steroids: a local MCP workbench for the ChatGPT you already run in Chrome
Cross-platform local MCP capabilities for ChatGPT with Chrome integration, Goal, Compact & Resume, and durable multi-agent workflows.
At a glance
- What is it?
- Chat On Steroids is an Electron tray app plus companion Chrome extension that gives ChatGPT file, shell and multi-chat tools through MCP. It is a beta with real permissions, unsigned builds, and a hard dependency on a browser extension for its most interesting features.
- Who is it for?
- Adopt it if you already pay for ChatGPT in a browser and want apply_patch, exec_command and worker chats against folders you approve, on a machine where you accept unsigned binaries and the AppImage's possible --no-sandbox fallback. Do not adopt it on a shared or managed workstation, on Linux if you need desktop computer control (there is no backend), or if you want a sandbox between the model and your shell: exec_command runs programs as your logged-in user.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between a ChatGPT text box and a working directory
ChatGPT's developer mode can call MCP servers, and the README's framing of the problem is blunt: most of those servers expose one narrow API. Chat On Steroids takes the opposite approach and ships a workbench. The intended user is someone who already runs ChatGPT in a browser and wants the model to touch real files and real processes rather than paste code back and forth. The README describes the app as a desktop chat workspace and local MCP server, with project folders, images, plans, worker chats, and tools to read, patch and run code. It hosts no model of its own, which is the design decision that shapes everything else: the intelligence stays in the ChatGPT session, and this project supplies hands. That also means the product is only as good as the browser session it attaches to, which is why the companion extension matters more than a typical add-on.
How the pieces fit: Electron host, MCP tools, and a brokered browser
The architecture visible in the material has three layers. An Electron tray application runs locally and acts as the MCP server that ChatGPT connects to. A companion Chrome extension (or Edge) provides the browser integration. Between them, the app brokers worker chats: one prime chat can spawn worker chats, hand them tasks, read their reports and wake them again later, and the README is explicit that workers are ordinary ChatGPT conversations in your own browser. That is a meaningful constraint and a meaningful feature at once. You can watch every worker, because they are just tabs you could have opened yourself. You also cannot run a worker without the extension, because there is no hidden API path. Tool calls are recorded locally with their real results, and Compact & Resume asks a heavy chat for a handoff brief, opens a fresh chat and moves the same local session across, so the new chat can query everything the old one did. The model discovery path in 2.0.8 reads the account's native picker state across languages and nested version menus, which tells you the integration depends on scraping or observing the ChatGPT UI rather than a stable private API. Expect that surface to move when ChatGPT's interface moves.
The tool contracts are ports of Codex CLI, and that is the interesting bet
apply_patch, exec_command and write_stdin are described as ports of the tool contracts OpenAI's Codex CLI uses, on the reasoning that the model already knows how to hold them. That is a cheaper bet than teaching a model a bespoke schema. Multi-file patches are preflighted before anything is written, and commands run as real processes with interactive stdin, output budgets and background results the model can collect later. Preflight is the part worth noting: it is a validation pass, not a sandbox. Once a patch passes, files are written. The permission boundary is folder approval plus per-capability switches plus a read-only kill switch, and the README states plainly that exec_command runs programs as your logged-in user. There is no container and no seccomp profile in the description. Treat the approved folder list as the actual blast radius, because that is what it is.
Installing it: packages, hashes, and the extension reload nobody remembers
Builds are published for Windows, macOS and Linux on x64 and ARM64, as installers, DMGs, ZIPs, AppImages and DEBs, with a standalone extension zip for manual installs and a SHA256SUMS.txt listing every hash. The README gives the verification commands directly: Get-FileHash .\Chat-On-Steroids-Setup-x64.exe -Algorithm SHA256 on Windows, shasum -a 256 on macOS, sha256sum on Linux. Windows and AppImage installs check GitHub for a newer release on start and every six hours, download it, verify its checksum and apply it when you quit or choose Install update, with staged downloads revalidated before installation. macOS and DEB installs link to the release page for manual installation. The update note at the top of the README is the operational gotcha: 2.0.8 needs its matching companion extension, and you must reload the unpacked extension after updating. A version-mismatched extension is the first thing to check when session attribution or worker chats stop working. Edge users pick Settings, Browser & history, ChatGPT browser, Microsoft Edge, then install the companion and sign in to ChatGPT in that browser's active profile. On macOS, Desktop permissions start off and are enabled in Settings, Workspace, after which Screen Recording and Accessibility must be granted in System Settings.
Unsigned builds, an update channel, and a sandbox fallback you should know about
The README states that builds are not publisher-signed yet and macOS builds are not notarized, so SmartScreen, Gatekeeper or the browser will warn. The suggested path is to verify the hash first and then use the normal run anyway flow, or build from source. That is a real friction cost for anyone distributing this inside an organisation, and it is not a temporary cosmetic issue: an unsigned auto-updater that downloads and applies releases on quit is exactly the mechanism a managed endpoint policy will block. On Linux there is a second, sharper detail. Debian and Ubuntu users are told to prefer the DEB because the AppImage uses electron-builder's static launcher, and on a host that disables unprivileged user namespaces that launcher can fall back to starting Chromium with --no-sandbox so the app still opens. The README does not hide this; it tells you to use the DEB if you do not want the fallback. If your threat model cares about Chromium sandboxing, that sentence decides your package format for you.
Where it is the wrong tool
Three cases stand out. First, headless or server-side use: the whole design assumes a desktop session with a signed-in browser profile, and without the extension you still get MCP tools but not session attribution, Compact & Resume, worker chats or the Goal loop. If those four features are why you are interested, the extension is not optional and the app is not a server component. Second, Linux desktop computer control: the README says Linux has Core tools but no Desktop computer-control backend, so a cross-platform expectation set by the marketing line does not hold there. Third, external MCP plugins. Settings, Plugins installs integrations such as Blender MCP, Playwright, Memory and Web Fetch behind a separate Chat On Steroids Plugins connector, and the README notes that external servers run with their own OS and service permissions, outside the approved-folder sandbox. Installing a plugin therefore widens the boundary that the rest of the product is built around. The read-only switch and folder approvals do not contain a plugin that decides to read your home directory. That is a design consequence, not a bug, but it is the one place where the project's own security story stops applying.
The alternative, and the actual difference in approach
The obvious comparison is to a general-purpose MCP server that exposes filesystem and shell tools over stdio, which you then point at a client such as a desktop coding agent or a self-hosted chat front end. The difference is not the tool list; apply_patch and exec_command are ports of contracts that already exist elsewhere. The difference is where the conversation lives. A general MCP server assumes the client owns the chat, the session and the transcript. Chat On Steroids assumes ChatGPT in your browser owns the chat, and it works around the consequences: it brokers worker chats as real browser conversations, it reconstructs session continuity by asking the old chat for a handoff brief and replaying the local record into a new one, and it depends on reading the account's picker state to know which model it is talking to. That is more moving parts and more exposure to UI changes than a stdio server that a client drives directly. In exchange you keep the ChatGPT subscription, the browser, and the ability to watch every worker. If you are already paying for an API-driven agent, this project is solving a problem you do not have.
Maintenance cost, licence, and what to check before trusting it with a repo
The release cadence visible in the material is aggressive: 2.0.6, 2.0.7 and 2.0.8 within four days, with release names that read like notes to self. Fast iteration on a project that patches files and spawns processes is a mixed signal. It means fixes arrive quickly; it also means the extension and the app must be kept in lockstep, and the README's own update warning confirms that mismatch is a real failure mode. Budget for reading the changelog before each update and reloading the unpacked extension afterwards. The licence is MIT, which is permissive and places the usual disclaimer of warranty on the software; because this tool writes to your files and executes commands as your user, the practical question is not the licence text but what you approve. Nothing here is legal advice, and the MIT grant does not shift the consequences of a bad patch onto anyone else. Before pointing it at anything you care about, verify the SHA256SUMS.txt hash, start with a scratch repository rather than a production checkout, keep read-only mode on until you have watched a few tool calls land, and leave external plugins off until you have decided whether you accept servers running outside the approved-folder sandbox.
Editorial conclusion
Adopt it if you already pay for ChatGPT in a browser and want apply_patch, exec_command and worker chats against folders you approve, on a machine where you accept unsigned binaries and the AppImage's possible --no-sandbox fallback. Do not adopt it on a shared or managed workstation, on Linux if you need desktop computer control (there is no backend), or if you want a sandbox between the model and your shell: exec_command runs programs as your logged-in user. Verify first that your Chrome is 116 or newer, that you can reload the unpacked extension after each update, and that the SHA256SUMS.txt hash matches your download before you grant any folder.
Community notes