# hanyi0000/chatgpt-plus-automation-toolkit: a Playwright pipeline for ChatGPT Plus signup, GoPay payment and OAuth export

> The repository automates five ChatGPT account workflows plus a separate PayPal path, driven by a Python CLI and a Windows control panel. It is a browser-automation toolkit with real operational dependencies, not a drop-in service.

**hanyi0000/chatgpt-plus-automation-toolkit** — 自动化完成 ChatGPT 账号注册、GoPay/PayPal 支付、OAuth 授权与 Session 导出，含 Windows 控制面板

- Repository: https://github.com/hanyi0000/chatgpt-plus-automation-toolkit
- Stars: 545 · Forks: 156
- Language: JavaScript
- License: MIT
- Published: 2026-09-20 · Updated: 2026-09-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/hanyi0000-chatgpt-plus-automation-toolkit

## The specific job this toolkit automates

Signing up for ChatGPT Plus by hand is a sequence of steps that each fail independently: create an account, receive a verification code, generate a payment link, complete a GoPay or PayPal billing flow, then authorize an OAuth client and keep the resulting refresh token. Doing that once is tedious. Doing it across a batch of accounts is a job for a script, and that is the gap this repository fills.

The README lists six flows. Flow one registers an account and produces a long payment link. Flow two drives GoPay: open the link, fill billing, bind GoPay, handle OTP, enter the PIN, finish payment. Flow three authorizes an already-paid account and writes the refresh_token to disk. Flow four extracts a session from a browser profile and exports it in sub2api format. Flow five registers free accounts by phone or email. PayPal Plus is a parallel path that combines iCloud registration, card binding through PayPal and OAuth authorization.

The audience is narrow by design. This is for someone running many accounts and willing to supply the mail pool, proxy pool, SMS platform keys and payment instruments the configuration expects. It is not a consumer app, and the README does not present it as one.

## How the flows are wired together

The entry point is main.py, which dispatches on a --mode argument and also exposes an interactive menu. Each flow lives in its own module: authorization_flow.py handles OAuth, fill_billing_test.py handles GoPay payment, and the modules/ directory holds the shared pieces. browser.py manages the browser session, including fingerprint generation and proxy assignment. chatgpt_register.py holds registration logic. checkout.py produces the payment long link. paypal_flow.py orchestrates the PayPal path, with paypal_register.py, paypal_pay.py, paypal_card_pool.py and paypal_phone_pool.py underneath it.

Data moves through files rather than a database. Inputs are plain text pools: data/accounts.txt for flow one, data/paypal/cards.txt for the card pool, data/paypal/phones.txt for phone numbers, data/paypal/icloud_accounts.txt for iCloud accounts, and data/proxies/proxies.txt for proxies. Outputs land in output/, with subdirectories such as output/授权输出/ and output/paypal成品/. The format is line-oriented, for example email----query_code----payment_link. A state_db.py file exists at the repository root, so some run state is tracked beyond the text files, though the README does not describe its schema.

The anti-detection layer is worth noting because it shapes the design. The README states that each account gets a fingerprint derived from the email seed, so the same mailbox presents a consistent User-Agent, screen resolution and US timezone across flow stages. Proxies are assigned per worker from a pool, with separate switches for the PayPal path (PAYPAL_USE_PROXY) and the global path (USE_PROXY). That consistency requirement is why the tool keeps browser profiles in profiles/ instead of starting clean each time.

## Installing it and running flow one

The README lists Python 3.10+ and Playwright as the requirements, with Windows, macOS and Linux all supported. Installation is two commands: install the Python dependencies, then install the Chromium build Playwright drives.

```bash
pip install -r requirements.txt
playwright install chromium
```

requirements.txt pins playwright>=1.45.0, PyYAML>=6.0.1, httpx>=0.27.0, requests>=2.31.0, pyinstaller>=6.0.0 and pytest>=8.0.0. The pyinstaller entry is there because the repository also ships a Windows control panel built from ChatGPTAssistantPanel/ and control_panel/, with build_panel.ps1 and deliver_panel.ps1 as the packaging scripts.

Configuration comes from a .env file copied from the example:

```bash
cp .env.example .env
```

The README is explicit that sensitive values belong in .env. At minimum you set MAIL_SOURCE (moemail, hotmail or icloud_query), the per-flow overrides such as FLOW1_MAIL_SOURCE, and MAIL_ACCOUNT_MODE, which defaults to pool. If you use the built-in MoeMail option you also fill MOEMAIL_BASE_URL, MOEMAIL_API_KEY and MOEMAIL_DOMAIN_WHITELIST. For proxies, set USE_PROXY=true and point PROXY_FILE at a file with one entry per line in the form http://user:pass@host:port, socks5://host:port or host:port.

With that in place, the interactive menu is the recommended start:

```bash
python main.py
```

The command-line equivalent for flow one runs a batch with a worker count:

```bash
python main.py --mode register --count 5 --workers 3
```

Successful accounts are written to output/流程1_注册成功长链接.txt in the format email----query_code----payment_link. If the file is empty, the README gives no troubleshooting section, so the first place to look is whether the mail pool entries in data/accounts.txt are valid and whether the SMS provider credentials for FLOW1_SMS_PROVIDER are set.

## Where the toolkit breaks down or is the wrong choice

The heaviest dependency is not software. Flow two requires a GoPay phone number, and the .env.example shows GOPAY_PHONE_1 through GOPAY_PHONE_3 plus a compatibility variable GOPAY_PHONES that maps three numbers onto worker-1, worker-2 and worker-3. That means concurrent GoPay payments are bounded by how many distinct phone numbers and PINs you can supply. There is no documented way to scale past the number of configured phones, and GOTPAY_PIN is a single value in the example, which suggests the PIN is shared across the configured numbers rather than per-phone.

The PayPal path has a similar shape. Cards and phones come from files, PAYPAL_PHONE_MAX_USES defaults to 5, and PAYPAL_BILLING_COUNTRY defaults to US. The card file format is positional and long: KW-ID, card number, expiry, CVV, phone, cardholder name, address, and an SMS API URL, separated by four hyphens. A single misplaced field silently breaks the parse, and the README does not document validation or error messages for malformed lines.

Captcha handling is the other honest limitation. PAYPAL_CAPTCHA_MODE has two values, manual and api. Manual pauses the run and waits up to PAYPAL_CAPTCHA_TIMEOUT seconds for a human. API mode supports CapSolver and 2Captcha, but the README qualifies that this applies to standard reCAPTCHA and hCaptcha. It does not claim coverage of every challenge PayPal may present. If your run depends on unattended operation, that qualification matters.

Finally, browser automation against a live signup flow is inherently fragile. The repository was last pushed on 2026-06-01, and nothing in the README describes a compatibility policy, a changelog or a release history. When ChatGPT or GoPay changes a form, the fix is a code change in this repository, not a configuration toggle.

## How it differs from browser extensions and manual workflows

The obvious alternative is a browser extension or a userscript that automates clicks inside a browser you are already logged into. That approach is lighter: no Python environment, no Playwright, no profile directory. It also cannot do what this repository does, because the flows here need their own browser context with a proxy binding, a fingerprint tied to a specific email, and a profile that persists between registration and authorization. An extension lives inside your existing session and inherits its identity.

The other alternative is doing it by hand with a spreadsheet tracking which account is at which stage. That is what the output files replace. The toolkit's output directories mirror the pipeline stages: 长链接账号 for accounts with a payment link, 待授权账号 for paid accounts awaiting OAuth, 授权成功 for accounts with a refresh token. A manual process has to reproduce that bookkeeping and the token extraction, including the sub2api_accounts.json export and the per-account token JSON files under tokens/.

The closer comparison is another automation framework, for example a general-purpose browser automation suite where you write the flow yourself. The difference is that this repository ships the flow logic, the file formats and the fingerprint handling as one package. You trade flexibility for a fixed set of stages that match its own directory layout.

## Maintenance, upgrade cost and the MIT licence

The repository is not archived, but the last push was on 2026-06-01. There are no retrieved releases, so upgrades happen by pulling main rather than by installing a version. That has a practical consequence for anyone running it in production: there is no version number to pin, and no release notes to read before updating. The .env.example is long and includes compatibility comments, such as the note that GOPAY_PHONES maps to worker-1/2/3 when the numbered variables are absent. That comment exists because the configuration changed at some point, and it is a signal that pulling a new commit can require revisiting your .env.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. It says nothing about the third-party services the toolkit talks to. Your obligations to MoeMail, HeroSMS, GrizzlySMS, 5sim, CapSolver, 2Captcha, PayPal and GoPay come from those providers' own terms, not from this repository's licence. The README does not discuss compliance with any platform's terms of service, and it does not need to for the MIT grant to apply to the code. That distinction is worth keeping straight, and it is not legal advice.

The maintenance cost sits mostly in the browser flows. The modules that touch ChatGPT, GoPay and PayPal pages are the ones that break when those pages change. The pool files, the proxy list and the storage layer are comparatively stable.

## Conclusion

Adopt it if you already operate the surrounding infrastructure the README assumes: a mail source such as MoeMail, Hotmail or iCloud query, a proxy list, an SMS provider account, and for the GoPay path a phone plus PIN. Skip it if you want a supported product with a documented upgrade path, or if you cannot supply the payment and phone assets it binds to. Before running anything, verify that your .env has a working MAIL_SOURCE, that data/proxies/proxies.txt exists if USE_PROXY is true, and that the GoPay phone fields match the workers you intend to run. The last push to main was on 2026-06-01, so check whether the flows still match the current ChatGPT and GoPay pages before you commit a batch to it.

## FAQ

### What is ChatGPT automation in the context of this toolkit?

Here it means driving the ChatGPT signup, payment and authorization steps through a scripted browser rather than by hand. The repository implements this with Playwright and exposes each stage as a mode: register, gopay, authorize, session-export and free-register.

### What are the limitations of chatgpt-plus-automation-toolkit?

Concurrent GoPay payments are bounded by the configured phone numbers, captcha solving in API mode is described as covering standard reCAPTCHA and hCaptcha only, and the flows depend on live third-party pages that can change. The README documents no rollback or troubleshooting procedure.

### What can I do with chatgpt-plus-automation-toolkit?

The README lists registration with payment-link generation, GoPay payment, OAuth authorization with refresh_token output, local session export in sub2api format, free account registration, and a separate PayPal registration, payment and authorization path.

## Sources

- [hanyi0000/chatgpt-plus-automation-toolkit on GitHub](https://github.com/hanyi0000/chatgpt-plus-automation-toolkit)
- [Issues](https://github.com/hanyi0000/chatgpt-plus-automation-toolkit/issues)
- [License: MIT](https://github.com/hanyi0000/chatgpt-plus-automation-toolkit/blob/main/LICENSE)
- [README](https://github.com/hanyi0000/chatgpt-plus-automation-toolkit/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hanyi0000-chatgpt-plus-automation-toolkit