GPT-Register-Tool: a Windows workbench for ChatGPT registration and OTP handling

What GPT-Register-Tool actually automates

The project targets a narrow, repetitive workflow: creating ChatGPT accounts from a pool of email addresses, polling those inboxes for the one-time code, keeping the resulting session material on disk, and later extracting payment links. Its README frames the whole thing as a workbench, and the repository layout backs that up. There is a WPF application under SmsWorkbench/, a Python package named sms_tool/, a services/ directory, a config schema, and a payment_methods.json file listing the payment rails it knows about.

The intended user is someone already running proxies and disposable mailboxes, not a casual end user. The README lists ReMail, CFWorker, iCloud code links, Microsoft Graph/OAuth, IMAP and Gmail IMAP as email sources, and names SMSBower for phone numbers. Each of those is an external account the operator must already hold. The tool orchestrates them; it does not supply them.

One design decision stands out. The README states that the registration flow only authenticates the account and saves the access token and session, and that it no longer generates payment links. Link extraction is a separate, explicitly triggered payment operation. That separation matters because it means a registration run cannot accidentally spend money or touch a checkout page.

The registration pipeline and where it stops

The README gives the main flow as a text diagram: an email source feeds ChatGPT email OTP registration, which yields an access token and session, with a stable HTTP 200 access-token probe acting as the boundary for what enters the account store. From there the data lands as session JSON plus a SQLite index, and the WPF desktop reads it.

The success criterion is worth reading twice. According to the README, a candidate account is only promoted into the active library if the access-token probe keeps returning HTTP 200 inside a stability window. A token that appears once and then fails is not treated as a success. Registration, OTP, session retrieval and the probe each record their own stage result, so an intermediate state is not reported as a completed account.

There is also a recovery path. The README says that after an account is created and an access token obtained, the candidate and a checkpoint are persisted before the probe runs, so a proxy or TLS failure during probing can resume from the checkpoint without repeating the email OTP and account creation. That is a sensible boundary, and it is the kind of detail that separates a tool built for batches from a demo script.

Sentinel token generation is handled separately, with distinct tokens for username_password_create, authorize_continue and oauth_create_account. The README states that if the device identifier in the token, cookie and headers disagree, the run terminates with sentinel_extract_failed rather than continuing with inconsistent state.

Installing GPT-Register-Tool and running the environment preflight

The README describes three installation routes: a signed installer from GitHub Releases, a portable zip, and a source checkout. All three end in the same place, and all three require Python dependencies to be installed separately even when you use the installer.

The source route is the most explicit. Clone the repository, install the pinned requirements, copy the example config, build the desktop app with the provided script, then launch the executable:

git clone https://github.com/2951461586/GPT-Register-Tool.git
cd GPT-Register-Tool
python -m pip install -r requirements.txt -c constraints.txt
copy config.example.json config.json
powershell -ExecutionPolicy Bypass -File .\SmsWorkbench\build_dotnet.ps1
.\dist\net10\SmsWorkbench.exe

The README is direct about the build script: the desktop program can only be compiled through SmsWorkbench/build_dotnet.ps1, and running dotnet build directly produces intermediate files without updating the dist/net10 workspace.

Before any of that is useful, the environment needs checking. The README provides a preflight script that verifies Node.js, Playwright Chromium and the key Python packages:

python scripts/preflight_env.py

Run it and expect a report on those three areas. The README warns that Node.js 18 or newer must be on PATH because the Sentinel quickjs extractor runs OpenAI's real sdk.js through node, and that its absence causes OTP to be silently lost during registration. It also notes that curl_cffi==0.16.0 is checked along with a chrome146 profile, and that older versions never reach the mailbox purchase or registration stage.

Once the app starts, configuration happens in the desktop Settings pages: proxy pools under network and payment, mailbox sources under email, and optional SMSBower, CPA and SUB2API parameters. One environment variable is documented as an alternative to the config file:

$env:REMAIL_API_KEY = "rk-your-key"

The README states that environment variables take precedence over config.json, and that keys saved through the settings page are written only to the local, Git-ignored config.json.

Where GPT-Register-Tool breaks or is the wrong choice

The most concrete limitation is stated plainly in the README: browser drivers do not bypass CAPTCHA. When a manual challenge appears, the run ends with manual_challenge_required and the existing account state is preserved. Anyone expecting unattended throughput past a challenge has the wrong tool.

Platform lock-in is the second constraint. Windows 10/11 x64 is the only supported target, the desktop layer is WPF on .NET 10, and the build script is a PowerShell file. There is no stated Linux or macOS path.

Dependency weight is the third. A working install pulls .NET 10 Desktop Runtime, Python 3.10 or newer, a pinned curl_cffi build, Node.js 18 or newer, a Playwright Chromium download, and an anti-detect browser such as Camoufox, CloakBrowser or RoxyBrowser depending on the chosen driver. The requirements file also carries tzdata with an explanatory comment: Windows ships no IANA timezone database, so without it every ZoneInfo lookup raises, which the comment says silently broke fingerprint offsets and sentinel timezone handling. That is a real failure mode, and it is invisible unless you read the dependency list.

Finally, the README does not document rollback, and the repository's licence is not stated anywhere in the README or the top-level files. Treat both as open questions before a production deployment.

Protocol driver versus browser drivers: the real trade-off

The registration driver is selected in Settings under registration and code reception, and the README says the default remains protocol. The alternative drivers are playwright, roxy, cloak and camoufox, with camoufox described as the current default browser driver.

The difference is not cosmetic. The protocol driver works over HTTP with curl_cffi and the Sentinel quickjs extractor. The browser drivers launch a real browser: Playwright starts local Chromium, roxy connects to a local RoxyBrowser API and takes over via CDP, cloak calls an installed CloakBrowser Python SDK, and camoufox calls an installed Camoufox anti-detect browser. The README states that browser drivers reuse the same email OTP, session extraction, access-token probe and persistence boundary as the protocol path, so the surrounding pipeline does not change.

What does change is scheduling. The README describes pulse scheduling (registration.pulse, with wave intervals and OTP-ban pauses) and a browser process pool (registration.browser_process_pool) that reuses browser contexts per process and retires them by health. Both work together with an account-to-proxy-slot binding: each account keeps the same registration egress for its whole lifecycle, and retries only refresh the session id rather than switching proxy members. The README explains the reasoning, namely that egress rotation can be read as proxy churn and lead to a ban. The process pool caches by (driver, headless, timeout), so accounts sharing an egress and header configuration reuse one browser process.

If you have no anti-detect browser installed and no RoxyBrowser API, the browser drivers are unavailable to you, and the README notes that a missing required field returns a redacted configuration error instead of falling back to protocol registration.

Concurrency, proxies and mailbox costs

Two numbers in the README shape how you budget a batch. Sentinel extraction defaults to two concurrent extractions, with sentinel_max_concurrency capped at 4, described as a balance between batch speed and Sentinel rate-limiting risk. And ReMail batch ordering extends the HTTP wait by two seconds per mailbox, with a floor of 30 seconds, overridable through email_registration.remail.batch_timeout.

Proxy separation is enforced by configuration rather than convention. The README says registration proxies, mailbox receiving proxies and payment protocol proxies are independent, and that mailbox receiving defaults to a local http://127.0.0.1:7897. Before claiming or purchasing a mailbox, the CLI preflights ChatGPT, Auth and Sentinel network segments in order and picks the first usable line from the registration proxy pool. If TLS, proxy or profile checks fail, no mailbox is consumed. That ordering is a cost control as much as a correctness control.

On the ReMail side, the README distinguishes purchase and code mailbox modes. A code order can only receive mail before receiveUntil, and an API key cannot substitute for an expired service token, so long-lived inbox access requires the purchase mode. Orders use an Idempotency-Key to prevent duplicate orders on retry, and the README says logs redact API keys and service tokens.

Maintenance, releases and licensing

The repository is not archived, and the last push was on 2026-09-13. Releases are dated rather than semantic: v2026.09.14, v2026.09.10 and v2026.09.08, all within the same week. That cadence suggests active work, but it also means version numbers carry no compatibility promise, so pinning to a specific release date is the safer habit.

Upgrade cost is dominated by the pinned dependencies. curl_cffi is pinned to 0.16.0, CloakBrowser is constrained to >=0.5.3,<0.6, and the README ties registration eligibility to the curl_cffi version and a chrome146 profile. A dependency bump is therefore not a routine operation: it can change whether registration runs at all. The requirements file also documents a past packaging bug, where nodriver was imported at two call sites but undeclared, so the PayPal fallback silently degraded to not installed on every fresh install. That history is a reason to re-run the preflight script after any dependency change.

The licence is not stated in the README or the top-level files, so redistribution terms, commercial use and modification rights cannot be assessed here. If you plan to ship this inside an organisation, resolve the licence question with the repository owner before deployment rather than after.

Editorial conclusion

Adopt GPT-Register-Tool if you run Windows 10/11 x64, already operate proxy and mailbox infrastructure, and want a local desktop console rather than a script per batch. Do not adopt it if you need Linux or macOS support, a documented licence, or a tool that solves CAPTCHA without human intervention. Before trusting it with real mailboxes, run python scripts/preflight_env.py and confirm that curl_cffi==0.16.0, Node.js 18+ and the Playwright Chromium build are all present, because the README states that a missing Node.js silently drops OTP during registration.

Frequently asked questions

Official sources

1. 2951461586/GPT-Register-Tool on GitHub
2. Issues
3. README
4. Releases