turb-gpt-free-register: five browser drivers for bulk ChatGPT signup and Codex OAuth

What turb-gpt-free-register actually automates

The project targets one narrow workflow: create ChatGPT accounts in bulk, then turn each one into a Codex OAuth credential. Everything else in the repository exists to serve that loop. The README describes it as a ChatGPT and OpenAI account registration tool with Codex OAuth authorization, and it is explicit that the project is a fork and extension of xiaoguzuiniu/gpt-free-register rather than an original codebase.

The audience is narrow too. This is not a tool for someone who wants one account. It assumes you have a proxy pool, a supply of mailboxes, and, for the Codex step, an SMS code platform. The README lists GrizzlySMS and a local L number service documented in L_API.md. If any of those three inputs is missing, the pipeline stops partway and you are left with partially registered accounts.

The repository ships source, config templates and docs only. Accounts, tokens, mailbox pools, Codex credentials and logs are excluded through .gitignore, and the README states that runtime data lives in turb.sqlite3 at the project root. That split matters when you evaluate it: nothing in the repository tells you how many accounts anyone has created with it, and the project does not publish releases.

Five registration drivers and what each one trades away

The central design decision is that registration is pluggable. One config key, REGISTRATION_DRIVER, selects between protocol, roxy, cloak, browser_use and skyvern. The same five values are available for the Codex step under CODEX_OAUTH_DRIVER, plus a same_as_registration option that reuses whatever the registration used.

The protocol driver is the original pure-protocol path built on curl_cffi with Sentinel and proof-of-work handling. It is the lightest option because no browser process starts, but it is also the most exposed to page changes, which is presumably why the browser drivers exist. The roxy driver drives RoxyBrowser through Selenium and handles the newer page flows: the create-account/password step, the about-you age and birthday forms, and localized pages. It creates, opens and closes one Roxy profile per account, and ROXY_OPEN_HEADLESS=True runs it without a visible window. The cloak driver uses CloakBrowser with a Playwright adaptation layer, supporting the free binary, headless mode, humanize behavior, a fixed fingerprint seed and geoip-based locale matching.

Two drivers do not run a browser on your machine at all. browser_use connects to Browser Use Cloud stealth Chromium over Playwright with an optional residential proxy, and skyvern uses Skyvern Browser Sessions over Playwright CDP. That is a genuine architectural difference, not a cosmetic one: the cloud drivers cannot participate in local traffic interception, resource blocking or JS coverage collection, which the README states plainly. If you want the bandwidth accounting described later in this article, you must stay on roxy or cloak.

Mail sources, SMS codes and where the account data lands

Registration is only half the problem. The tool has to receive a verification code, and the README lists a wide set of mail backends: an Outlook pool in email----password----clientId----refreshToken format, Cloudflare domain mailboxes read over QQ IMAP, a Cloudflare Worker temporary mailbox with JWT code retrieval that is compatible with cloudflare_temp_email, a generic API mailbox given as email plus a code-fetch URL, a generic IMAP pool configured per line with server, port and SSL set in the import screen, GPTMail temporary mailboxes, and Remail short-lived mailboxes ordered per project. EMAIL_SOURCE accepts a comma-separated combination such as outlook,generic_api,imap.

That breadth is a hedge. Each source has its own failure mode, and mixing them in one run means a broken source degrades throughput rather than stopping the job. The trade-off is configuration surface: every source needs its own credentials in .env, and the README does not document a per-source health check.

For Codex, the tool generates an authorization URL through a CPA management interface, submits the OAuth callback, and handles the phone step with automatic number acquisition, form filling, code retrieval, submission and retry on a new number after failure. Credentials are written to the codex_accounts table. All runtime state lives in turb.sqlite3, split across accounts, email_pool, registration_jobs, codex_accounts and codex_agent_accounts. The database uses WAL mode, a busy timeout and indexes, and the WebUI paginates with SQLite COUNT(*) plus LIMIT/OFFSET instead of loading everything into Python. On first start it migrates existing JSON and historical SQLite data, and after migration it stops reading and writing the old JSON and TXT files.

Installing turb-gpt-free-register and registering one account

The environment requirements are Python 3.10+ and Node.js 18+, plus a working proxy, system VPN or a RoxyBrowser proxy environment. The README gives the dependency install as a pip command followed by a Node version check.

pip install -r requirements.txt
node --version

The requirements file pins curl_cffi, pyotp, flask, requests, pycryptodome and selenium, and adds cryptography, cloakbrowser[geoip], playwright, python-dotenv and playwright-stealth. CloakBrowser downloads its Chromium binary on first run, and CLOAK_GEOIP=True needs the geoip extra.

Configuration goes in a .env at the project root, copied from the template. The README is emphatic that API keys belong there and not in config/*.py.

cp .env.example .env

The template documents WEBUI_AUTH_CODE, which is the WebUI login code and is kept in .env so it does not appear in the process command line. WEBUI_SESSION_SECRET is optional; if left empty it is derived from the fixed auth code, so changing the code invalidates existing sessions.

To run the pipeline you pick a driver and a mail source. The template lists the relevant keys, including the driver, the Cloak switches and the mail source combination:

REGISTRATION_DRIVER=
CLOAK_HEADLESS=
CLOAK_HUMANIZE=
CLOAK_GEOIP=
EMAIL_SOURCE=
ENABLE_CODEX_AUTO=

The README recommends the WebUI for daily use, launched through webui.sh, with the CLI as the alternative. In the WebUI you start a batch registration job, watch the task log live, and adjust the registration thread count; the README states that submitted changes apply to new jobs immediately. The account page supports rebinding a mailbox for one account or many, showing both the original and current address, and refreshing the access token. There is one behaviour worth knowing before your first import: mailbox pool import does not create accounts by default, but ticking the option to treat imported mailboxes as successfully registered marks them as used and lets you batch-run Codex against them.

The data saver mode and why the README warns you about it

Browser-driven registration pulls a lot of bytes, and the project added a bandwidth saver for roxy and cloak. It is enabled either in the WebUI under the browser profile settings or in .env, and it only applies to those two drivers.

BROWSER_DATA_SAVER_MODE=True
BROWSER_DATA_SAVER_BLOCKED_RESOURCE_TYPES=["image", "media"]

The default rules block image and media types plus a list of RUM and advertising URLs. Roxy disables image loading in the launch arguments and uses Chrome CDP to intercept common image and media suffixes plus configured URL globs; Cloak uses Playwright to block by resource type and URL glob. Playwright will let through URLs containing captcha or challenge keywords, but the README notes that Roxy's Chromium image switch and CDP URL blacklist cannot express URL exceptions, so if a captcha or layout problem appears you have to turn the mode off and retry.

The README is unusually candid about the risk here, and it is the most useful part of the documentation. It records that blocking the chunk 7aaae702-*.js in one job caused the OTP input box to go missing, while allowing that chunk in a later job let registration complete. The stated conclusion is that you cannot block a CDN chunk just because it has a low function execution ratio. It also warns against blocking the core scripts and endpoints: chatgpt.com/cdn/assets/*.js, auth-cdn.oaistatic.com/assets/*.js, sentinel.openai.com, chatgpt.com/backend-api/sentinel/*, ab.chatgpt.com/v1/initialize and chatgpt.com/realtime/wm.

Two diagnostic switches support this tuning. BROWSER_TRAFFIC_DETAIL_LOG with BROWSER_TRAFFIC_DETAIL_MAX_ENTRIES prints a per-resource breakdown sorted by total bytes, including status codes and failed, blocked, unfinished and cache states. BROWSER_JS_COVERAGE_LOG with BROWSER_JS_COVERAGE_MAX_ENTRIES uses CDP Profiler.startPreciseCoverage to show which functions actually ran. Neither works on the cloud drivers. If the fingerprint browser does not support the CDP profiler, the log marks supported=False and registration is unaffected.

Where turb-gpt-free-register breaks or is the wrong choice

The clearest limitation is the cloud driver gap. Browser Use and Skyvern sessions run remotely, so the local traffic listener, resource interception and JS coverage collection are all disabled, and the README says the full page resources are always kept. If bandwidth accounting is part of why you picked this tool, the cloud drivers quietly remove it.

The second limitation is the protocol driver's fragility. The README frames the browser drivers as handling newer page flows, which implies the pure-protocol path does not always keep up. A page change on OpenAI's side can break protocol registration while the browser drivers continue, and the reverse is also true. There is no documented rollback or version pinning for the protocol path.

Third, the tool depends on external services you have to supply and maintain: proxies, mailboxes, and for Codex a phone number provider. The README documents GrizzlySMS and a local L service, and nothing else. If your provider changes its API, the Codex step fails after the account already exists, leaving a registered account without credentials.

Finally, there is a licensing and operational question the repository does not answer. The project is MIT, which covers the code, but automating account creation against a third party's terms of service is a separate matter that the README does not discuss. The README also states that runtime data in turb.sqlite3 is gitignored and should be included in your backup strategy, which is a hint that losing that file loses your accounts and credentials.

How it compares to plain Playwright or Selenium automation

A reasonable alternative is writing your own Playwright script: launch a browser, fill the signup form, poll a mailbox API, submit the code. That approach gives you full control and no dependency on a five-driver abstraction, and for a handful of accounts it is less work than configuring this project's .env surface.

The difference in approach is where the complexity sits. A hand-written script handles one page flow. turb-gpt-free-register handles the variations the README enumerates: email submitted and straight to a code page, email submitted and redirected to create-account/password first, an about-you page that wants an age number, an about-you page that wants a full birthday, React Aria birthday controls, and button reordering across locales that causes accidental clicks on third-party sign-in. It also persists state in SQLite, paginates it in a WebUI, and chains the Codex OAuth flow with SMS retries. Those are the parts you would otherwise rebuild.

The trade-off is the opposite of control. You inherit five drivers, a large configuration surface, and a tuning problem in the data saver mode that the README itself demonstrates can break registration if you block the wrong chunk. If your goal is one account, or if you want to understand every network request, a small Playwright script is the better tool. This project earns its place when the account count is high enough that mailbox handling, retries and credential storage become the actual work.

Maintenance, licence and upgrade cost

The repository is not archived, and its last push was on 2026-09-17. There are no retrieved releases, so upgrades mean pulling the main branch rather than tracking version tags, and there is no changelog in the repository to tell you what changed between pulls.

The licence is MIT. That permits commercial use and modification, but it says nothing about the third-party services the tool drives, and the README does not address terms of service, account bans or data protection. Treat the MIT grant as covering the code only.

The upgrade cost is concentrated in three places. The .env surface is large, and the template documents dozens of keys across Cloak, Browser Use, Skyvern and the mail sources, so a config written against an older revision may not match current defaults. The database migrates automatically on first start from JSON and historical SQLite, which is convenient once but means you should back up turb.sqlite3 before pulling. And the data saver URL rules are version-sensitive: the README's own example shows a chunk that broke OTP input in one job and worked in another, so any rule you tuned needs re-verification after an upgrade rather than being carried forward on faith.

Editorial conclusion

Adopt it if you already run RoxyBrowser or CloakBrowser and need many ChatGPT accounts plus Codex OAuth credentials in one pipeline, and you are willing to keep proxy, mailbox and SMS infrastructure alive around it. Do not adopt it if you need one account, if you cannot supply a working mail source, or if you expect the protocol driver to survive an OpenAI page change without a browser fallback. Before committing, verify three things in your own environment: that your chosen REGISTRATION_DRIVER completes a single account end to end, that turb.sqlite3 is inside your backup set, and that your SMS provider is actually wired for the Codex step.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. myfanhua/turb-gpt-free-register on GitHub
4. README