FlowPilot: a Chrome side panel for batch ChatGPT, Kiro and Grok account registration

Who FlowPilot is for, and what it replaces

The README is explicit that FlowPilot is not a single-button script. It is a Chrome side panel extension that puts registration, verification-code collection, OAuth consent, account delivery, retries and record keeping into one tool. The problem it addresses is the gap between those steps: an account is only useful once the email is confirmed, the OAuth consent page is approved, and the resulting credential reaches a downstream target. Doing that by hand across a batch is where the tool earns its place.

The intended user is someone running an OpenAI-compatible aggregation endpoint. The README lists CPA, SUB2API and Codex2API as OpenAI sources, plus separate Kiro and Grok flows. Those names are the delivery destinations, not generic concepts, and the extension assumes you have one. If you do not operate such a target, most of the delivery configuration has nothing to point at.

A secondary audience is anyone already using residential proxies for this kind of work. The README carries a sponsor section for IPWO residential proxies aimed at AI automation and multi-account scenarios, with a discount code 0204. That is an advertisement, not a technical dependency, but it signals the operating context the author expects.

How a run is structured: flows, sources and delivery routes

The architecture visible in the repository is a side panel driving background and content scripts. Top-level entries include background.js and a background/ directory, content/, core/, flows/, sidepanel/, shared/ and a manifest.json. That layout matches the described behaviour: the side panel chooses a flow and source, the flow code drives page interactions through content scripts, and background code handles polling and uploads.

The README describes two execution styles. You can run individual steps manually, or run the whole chain with Auto. Stop, pause-then-resume, manual skip and failure retry are all listed as supported. The record panel shows successes, failures, stops, retry counts, and the email/phone identity combination used in the same round.

Delivery is where the design gets specific. For OpenAI flows, the source determines which delivery methods appear. CPA offers OAuth or ChatGPT Session. SUB2API offers OAuth, ChatGPT Session or Agent Identity. Codex2API is fixed to OAuth. webchat and ChatGPT2API are fixed to ChatGPT Session, so the README says no delivery selector is shown for them. Preferences are saved per target and restored when you switch back.

One detail worth flagging: the README states that Agent Identity runs a SUB2API pre-check, then generates the identity in memory and imports it, and that the raw ChatGPT access token, private key and full sensitive payload are not written to persistent settings or logs. That is a claim about storage behaviour, not something a reader can confirm without reading core/.

Installing FlowPilot as an unpacked Chrome extension

There is no package registry install. The README's quick start loads the repository directory directly into Chrome, which means you need the source checked out locally first.

Open the extensions page and enable developer mode:

chrome://extensions/

The README then instructs you to click "Load unpacked" and select the project directory. After that, open the extension side panel and pick the flow and source you want to run.

The repository also ships helper launchers at the top level. On Windows there is start-custom-mail-helper.bat and start-hotmail-helper.bat; on macOS there are start-custom-mail-helper.command and start-hotmail-helper.command. These correspond to the local helper modes the README mentions for Hotmail and for reading account records from data/account-run-history.json.

For development, package.json defines a single script:

npm test

That runs node --test tests/*.test.js. The package is marked private and licensed MIT. There is no build step described, which fits an extension loaded straight from source.

The README's own advice for a first run is to configure email, verification-code source, account delivery method and target parameters, then manually run the first few steps before switching to Auto for the full chain.

Email and verification-code handling is the real surface area

The longest list in the README is the mail support matrix, and that is not an accident. Registration automation lives or dies on whether it can read a code out of a mailbox. FlowPilot supports Hotmail, 2925, QQ Mail, 163 Mail, 163 VIP Mail, 126 Mail, Inbucket, Cloud Mail, YYDS Mail and iCloud, and the repository has matching utilities at the top level: hotmail-utils.js, mail2925-utils.js, cloudmail-utils.js, cloudflare-temp-email-utils.js, icloud-utils.js, yyds-mail-utils.js and luckmail-utils.js.

Registration addresses can come from DuckDuckGo, Cloudflare, a custom email pool, a custom email service account pool, or Gmail / 2925 aliases. The README notes that the custom pools can be tied to the automatic run count, so the pool drains in step with the batch.

Some providers carry their own state machines. The README says 2925 supports a multi-account pool with automatic login, automatic account switching and a 24-hour cooldown. Hotmail supports a remote service mode and a local helper mode. Polling comes in three shapes: web mailbox polling, API mailbox polling, and local helper reads.

The operational delay setting is worth understanding before you tune anything. It defaults to on with a value of 2 seconds, and it governs clicks, typing and short waits inside the page. The README is clear that it does not affect email code polling, SMS code polling, OTP polling, or the pacing of background steps such as confirm-oauth and platform-verify. So raising it will not slow down, or speed up, the parts most likely to be rate-limited.

Where FlowPilot is the wrong tool

Plus is not available. The README states that the side panel and entry points hide and close Plus, that old configurations are forcibly normalized to off, and that the PayPal, Hosted and unpaid implementations survive only as dormant code for a future restore. Anyone who needs Plus should treat this project as not offering it, regardless of what older material or forks suggest.

Second, this is a browser extension, not a server pipeline. It runs in a Chrome side panel and drives page interactions. If your requirement is headless batch execution on a build machine, the architecture is pointed the wrong way, and the local helper scripts exist precisely because some inputs (Hotmail, custom mail, record history) live outside the browser.

Third, the delivery configuration is opinionated. Agent Identity is only reachable through SUB2API, and the README says delivery method is not editable during a workflow run, while settings are locked, or in contribution mode, where OAuth is forced. If your process needs to switch delivery mid-run, this design will block you.

Finally, the documentation is split. The README says to read the two technical documents (项目完整链路说明.md and 项目文件结构说明.md) if you are developing, adding steps or debugging runtime state. The README alone will not explain failure modes, and it does not document rollback of a partially completed batch.

FlowPilot compared with a general browser automation framework

The closest alternative in kind is a general browser automation stack such as Playwright or Puppeteer scripts. The difference is where the knowledge lives. With a general framework you write the selectors, the consent-page handling, the mailbox polling and the retry logic yourself, and you own every change the target site makes. FlowPilot ships that as flows/ and content/ code plus a side panel, so the registration and OAuth steps are already encoded.

The trade is control. A Playwright script can run headless on a server and be versioned like any other service; FlowPilot is bound to a Chrome profile and a side panel, and its mail integrations are a fixed list. If your mail provider is not on that list, the framework route is more flexible. If it is, FlowPilot saves you from rebuilding verification-code polling for ten providers.

A second reference point is the recording and retry layer. FlowPilot's record panel and data/account-run-history.json give per-round visibility into which email and phone identity was used and why a run stopped. That is a feature most hand-rolled scripts lack, and it is the part that matters once a batch is large enough that you cannot watch it.

Editorial conclusion

Adopt FlowPilot if you already operate a CPA, SUB2API or Codex2API endpoint and need the registration, verification-code and OAuth steps chained into one runnable flow with retries and a record panel. Do not adopt it if you need Plus, which the README states is hidden and forced off, or if you want a headless server-side pipeline rather than a browser side panel. Before committing, verify which email provider you can actually wire up (Hotmail, 2925, QQ Mail, 163 Mail, 163 VIP Mail, 126 Mail, Inbucket, Cloud Mail, YYDS Mail or iCloud), and confirm the target's delivery route, since Codex2API is fixed to OAuth while webchat and ChatGPT2API are fixed to ChatGPT Session.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. QLHazyCoder/FlowPilot on GitHub
4. README
5. Releases