# Grok-Register: a bulk signup pipeline that tells you it is already broken > A Go CLI that chains free Grok account signup, OAuth exchange and JSON export behind one command, built on TLS fingerprinting, a Docker clearance stack and an offscreen Turnstile pool, and now parked by its own author. **Charles-0509/Grok-Register** — Grok free-register CLI: register → OAuth → CPA JSON (Go) - Repository: https://github.com/Charles-0509/Grok-Register - Stars: 522 · Forks: 171 - Language: Python - License: not declared - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/charles-0509-grok-register ## One command, three deliverables The repository describes itself as a two in one CLI for free Grok registration, taking an account from signup through the OAuth exchange to a CPA usable JSON file. The short version on the repository description spells out the same three stages in English: register, OAuth, then CPA JSON. The output is meant to be dropped straight into a gateway such as CPA or a cliproxy style proxy pool, so the pipeline does not stop at a credential. The command surface is deliberately small, and that is the most useful thing about it, because the process runs in the background and you interact with it afterwards rather than sitting in front of a prompt. ```bash grok start grok start -t 10 --thread 2 grok status grok logs -f grok stop grok config grok upload ``` Six verbs cover the lifecycle. `start` takes a target count and a thread count, `status` and `logs -f` are how you watch a run you launched, `stop` ends it, `config` opens the environment file, and `upload` retries the final handoff. There is a scheduler shape here rather than a one-shot script shape, with a PID file and logs under the data directory so a run survives your terminal closing. The per-run outputs are organised under an outputs directory keyed by run, and there is one format specifically for other tooling: a grok2api export at `outputs//grok2api/tokens.txt` containing nothing but SSO tokens, one per line. That file exists so the accounts can be fed to a different consumer without redoing the OAuth work, which tells you the author expects the credentials to outlive the tool that made them. ## The three legs: protocol, edge, challenge The architecture section compresses the design into three lines, and the compression is useful because each line answers a different question about why an automated signup gets blocked. The protocol leg is the happy path. Rather than driving a browser through the whole signup form, the CLI speaks the same request sequence the site uses: a gRPC call to send and verify the email code, a Server Action for the form submission, a hop through the SSO endpoint, then the OAuth exchange, then a liveness probe and the CPA payload. Most of the work happens without a page ever rendering. The edge leg is what happens when the happy path is noticed. Cloudflare sees a TLS fingerprint that does not match a real browser, and the response is a block rather than a form. The primary defence is a Go TLS client configured to present a `chrome_131` fingerprint. The fallback, selected by `CLEARANCE_MODE=auto`, is to bring up the clearance stack so the request goes out over WARP with FlareSolverr in front of it. The challenge leg is the part that cannot be faked cheaply. Turnstile is solved with an actual Chromium, and the README is candid that this is Chromium only, not pure headless. The default is `TURNSTILE_MODE=offscreen`, described as not true headless, and the stated purpose is to reduce the 600010 error code rather than to look invisible. There are two mint helpers, a one-shot script and a persistent pool, which is the difference between launching a browser per token and keeping a warm one around. There is also a smoke command that registers nothing, which is the right shape for the first thing you should run. ```bash go run scripts/smoke_protocol.go REGISTER_PROXY=http://127.0.0.1:7890 go run scripts/smoke_protocol.go ``` ## The clearance stack is three containers and a hard dependency The Docker side is not a convenience wrapper around the binary. The compose file starts WARP, Privoxy and FlareSolverr, and the grok service declares `depends_on` both proxies with `condition: service_healthy`, so the CLI will not start until the egress path is genuinely up. The three published ports are WARP SOCKS5 on 40000, Privoxy HTTP for host egress on 40080, and FlareSolverr on 8191, all bound to loopback. WARP gives a residential looking exit address. Privoxy turns that into an ordinary HTTP proxy the Go code can point `REGISTER_PROXY` at. FlareSolverr is the fallback for pages that refuse a plain request, solving the Cloudflare interstitial with a real browser and handing back cookies. The ordering matters: TLS fingerprinting first, clearance only when the fingerprint fails, because the clearance path is slower and heavier. The compose file targets Windows and Docker Desktop specifically, and the comments explain why in a way that says a lot about the intended audience. The data volume maps `./data` on the host, so the SSO and CPA output is visible in File Explorer without entering the container. The container itself maps no ports at all, on the stated grounds that the CLI listens on nothing and its traffic originates inside. The default mode is `idle`, which keeps the container alive for `docker exec` rather than running a batch and exiting. ```bash docker compose up -d docker exec -it grok-reg grok help docker exec -it grok-reg grok start -t 10 docker exec -it grok-reg grok status docker exec -it grok-reg grok logs -f docker exec -it grok-reg grok stop ``` One feature is about failure recovery rather than throughput. With `CLEARANCE_AUTO_STOP=1`, running `grok stop` also runs `docker compose stop`, so tearing down a run also tears down the network stack instead of leaving three containers and a browser burning memory. ## Installation: an installer script, a Makefile and a per platform table Installation is handled by `scripts/install.sh`, which detects the platform and asks three questions when it has a real terminal attached. The questions are about the command name and paths, whether to bring up the WARP clearance stack, and whether to stop those containers when a run finishes. The answers write into a config file generated from `config.env.example`, with per section comments. The path handling is the part worth reading, because it solves a real installer bug. Under `sudo`, data goes to the invoking user's home, taken from `SUDO_USER`, rather than to root's home. On Linux that means `/home//.grok` instead of `/root/.grok`, and the source tree lands in `/opt/Grok-Register` with the binary in `/usr/local/bin`. On macOS the script requires Homebrew and Docker Desktop, refuses to run under `sudo`, installs the source into `~/Grok-Register` with the binary in `~/.local/bin` and the Python venv under `~/.local/share`, and appends the PATH to your shell profile. ```bash curl -fsSL https://raw.githubusercontent.com/Charles-0509/Grok-Register/main/scripts/install.sh | sudo bash ``` The macOS equivalent drops the `sudo`, and the README is emphatic about that. There are also non interactive variants for piping into a headless environment, where `--with-warp`, `--no-warp --proxy-port 7890`, `--no-warp` for a direct overseas VPS, and `NONINTERACTIVE=1` pick between the paths the questions would otherwise ask about. A dozen flags expose the same choices individually: `--command`, `--install-dir`, `--home`, `--bin-dir`, `--share-dir`, `--venv-dir`, plus `--skip-docker`, `--skip-clearance`, `--skip-browser`, `--skip-go` and `--no-start-clearance`. For people who already have the source, the Makefile is the smaller path, and it resolves the Go binary explicitly rather than trusting PATH. ```bash make build && sudo make install # Linux make build && make install PREFIX="$HOME/.local" APP=grok ``` That `GO ?=` block in the Makefile searches `/usr/local/go/bin`, the distro Go directories, and the per user locations in order, because `sudo` routinely drops PATH and the failure mode without it is a confusing not found error rather than a clear message. ## What the system needs, in memory as well as in software The requirements table is written as consequences rather than as a shopping list. Go 1.21 or newer is only for compiling the CLI, and without it you cannot build. Python 3.10 with a venv plus Playwright and CloakBrowser exist for the Turnstile mint, and without them you get a timeout or `iframes=0`, which is the signature of trying to solve a challenge with no browser. Docker is described as strongly recommended, with the honest note that registration, email and Cloudflare are more likely to fail without it. A CPA Management endpoint is optional, because the JSON files land locally regardless. The hardware guidance is the most useful part of the README and it is stated as ranges. A minimum workable setup is 2 GiB of memory with an equal amount of swap and one or two vCPUs, restricted to `--thread 1`. A comfortable setup is 4 GiB with two to four vCPUs and one or two threads. A high volume setup is 8 GiB or more with four or more vCPUs and three or four threads, past which the gains flatten. The rough per component breakdown is given as well: 400 to 900 MiB for WARP, Privoxy and FlareSolverr together, 300 to 800 MiB for a single CloakBrowser instance, 50 to 150 MiB for the CLI and the Python mint, and 200 to 400 MiB for system and Docker overhead. The total is given as roughly 1.2 to 2.5 GiB peak for a single threaded run of one account. Machines with 1 GiB or less are called out as very slow because of swap pressure, with four optimisations suggested: stay at one thread, guarantee at least 2 GiB of swap, let the clearance containers reach healthy before starting, and avoid pulling image layers in parallel with the browser launch. Those numbers are also the clearest statement of what this design costs. A pipeline whose happy path is pure HTTP still needs a browser and a proxy stack resident, because the fallback is what keeps it working. ## Small correctness details that only show up under load Several of the listed features exist to fix races rather than to add capability, and those tend to be the most trustworthy entries in any project README like this. A global seat cap keeps `done + reserved` at or below the target. Without a reservation counter, concurrent threads each believe they have room, and the run overshoots the number of accounts you asked for. Email handling offers two modes: `testmail` through a hosted service, and `cf_temp_email` pointed at a self hosted Worker, which is the route for anyone who does not want a third party holding their mail. OAuth is rate limited with a global interval, a discovery cache, and retries on rate limited responses, all three of which are the difference between a stable run and a run that trips a limiter halfway through. The Management upload gets its own wait. The CLI blocks before exiting until the CPA upload finishes, because the alternative is a process that exits while an upload is still in flight and silently loses the last batch. The Castle risk token is currently sent as an empty string, with a note that it will be filled in offline once the risk checks tighten, which is an honest admission of a known gap rather than a workaround dressed up as a feature. The Makefile has one small touch worth copying: `install` does not force a rebuild. If the binary already exists it installs that, specifically to avoid the case where `sudo` loses PATH and the install step tries and fails to compile again. ## The maintenance notice, and what it tells you about the approach The README contains a section titled as a failure notice, and it is worth quoting the reasoning rather than paraphrasing it. The stated cause is that xAI changed the registration mechanism and raised the threshold for automated signup, which made the registration machine break repeatedly. The second half is about the other end of the pipeline: the Grok accounts, when proxied through CliProxyAPI, expose model endpoints for grok-4.5 and grok-4.6 that xAI's backend actually forwards to lighter CLI assistant models distilled from early Grok 1 and 1.5, which are described as weak on Chinese comprehension, logical reasoning and code generation. The conclusion drawn is that the project has stopped maintenance as of that notice. There is a real tension in the repository state worth naming. The last push is dated 2026-09-07, so the code is being touched, and the repository is not archived, has 523 stars, 172 forks and nine open issues. There are no releases at all and no license file, which means the default copyright applies and there is no explicit grant to reuse the code. That combination, active commits with no license, is common in this category of project and it does matter if you were planning to fork rather than run. The deeper point is structural. A signup automation tool is coupled to the exact request sequence, token format and risk signals of a service that has every incentive to detect and break it, and the coupling is total. The protocol leg has no fallback if the Server Action changes shape. The edge leg depends on a specific TLS fingerprint being current. The challenge leg depends on Cloudflare continuing to accept a real Chromium solving a token in that way. Every one of those is a moving target on the other side, and the owner is reporting that the moving targets win. That makes the project a useful read for anyone building browser automation against an actively defended endpoint, since the failure modes are documented rather than implied. It is not a foundation to build a service on, and the author says so in the first screen of the README. ## Conclusion Grok-Register is worth reading as an engineering case study rather than a tool to adopt, because the author left the postmortem in the README instead of deleting the repository. The pipeline shape is legible: protocol requests first, edge fingerprinting as the fallback, and a real browser only where a real browser is unavoidable. Every layer has a config switch, a documented default, and a stated failure mode, which is more than most automation projects manage. Against that, there is no license, no release history, nine open issues, and an explicit statement that registration breaks whenever xAI changes its signup flow, which is a structural property of the approach rather than a temporary bug. The token endpoints have the same issue. Anyone evaluating this should assume the hard parts are the parts outside the repository: the email provider, the residential network, and the willingness to keep repairing a client against an API that is designed to resist it. ## FAQ ### What does Grok-Register actually do? It is a Go CLI that automates creating free Grok accounts, running each new account through the OAuth exchange, and writing the result as a CPA usable JSON file. One command starts a background run with a target account count and a thread count, and the JSON output can be loaded into a CPA or cliproxy style gateway. ### How does it get past Cloudflare and Turnstile? In three layers. The protocol leg does most of the work with plain requests, following the same sequence the site uses. The edge leg presents a `chrome_131` TLS fingerprint through a Go TLS client, and falls back to the Docker clearance stack, meaning WARP plus Privoxy plus FlareSolverr, when Cloudflare blocks it. The challenge leg solves Turnstile with a real Chromium in offscreen mode rather than pure headless, using either a one-shot script or a persistent pool. ### Is Grok-Register still maintained? The README states that the project has stopped maintenance, because xAI changed the registration mechanism and raised the threshold for automated signup, and because the proxied model endpoints resolve to lighter models with weaker reasoning than the names suggest. The last push is dated 2026-09-07, there are no releases, and no license file is present, so there is no explicit reuse grant. ### What hardware does it need? The README gives a minimum workable setup of 2 GiB of memory plus 2 GiB of swap with one or two vCPUs, restricted to one thread. A comfortable setup is 4 GiB with two to four vCPUs, and a high volume setup is 8 GiB or more with four or more vCPUs. Estimated peak memory for a single threaded run of one account is roughly 1.2 to 2.5 GiB, and machines with 1 GiB or less are described as very slow. ### Where do the accounts and tokens end up? Runs write under an outputs directory keyed by run, including CPA JSON files and a grok2api export at `outputs//grok2api/tokens.txt` that contains only SSO tokens, one per line. The compose file mounts `./data` from the host so the output is visible without entering the container, and `grok upload` can push the JSON to a CPA Management API, with the CLI waiting for that upload before it exits. ## Sources - [Charles-0509/Grok-Register on GitHub](https://github.com/Charles-0509/Grok-Register) - [Issues](https://github.com/Charles-0509/Grok-Register/issues) - [README](https://github.com/Charles-0509/Grok-Register/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/charles-0509-grok-register