# grok-register-panel: batch Grok registration with a live panel

> The project wraps Camoufox-driven registration in a task orchestrator, proxy pool and token-protected monitoring panel. It is a tool for controlled automation research, not a consumer way to reach Grok.

**lij768423-svg/grok-register-panel** — Grok 批量注册 (Camoufox) + 实时 Web 监控面板 | Batch Grok registration engine with live panel — concurrency · ASN blacklist · proxy pool · token auth

- Repository: https://github.com/lij768423-svg/grok-register-panel
- Website: https://lij768423-svg.github.io/grok-register-panel/
- Stars: 914 · Forks: 276
- Language: Python
- License: MIT
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/lij768423-svg-grok-register-panel

## What grok-register-panel actually automates

The README describes the full chain in one line: email OTP, profile page, Turnstile, SSO, Device or OAuth, then a write into CPA or Grok2API. That is the unit of work. Around it sits an orchestrator that runs multiple batches, pauses when risk control hits a threshold, and extends an ASN blacklist. The panel is the control surface: start and stop, concurrency, rerun N, blacklist, success rate by time window, proxy traffic for the current batch, account backfill, SSO risk scanning and BFS scanning.

The intended user is someone running registration flows in their own environment, not someone who wants a Grok account. The README states this plainly in its disclaimer: automated-flow research, own-environment integration and personal study, with a note to follow xAI, mailbox and proxy provider terms. The repository is a fork built on AaronL725/grok-register, which is also MIT. If you only want to reach Grok as a user, this project is the wrong layer entirely; it is the machine that creates accounts, not a client that talks to the model.

## The architecture: Camoufox workers, a local proxy port, and a panel on 8787

The architecture diagram in the README is worth reading literally. Multiple Camoufox workers send traffic through an HTTP proxy to a local mixed port on 127.0.0.1:79xx, which optionally chains to a residential exit. SSO and Device Flow output lands in cpa_auth/ and grok2api_auth/. The webui/monitor process reads log/register_results.jsonl and the CPA directory, and exposes a live panel on port 8787 behind a Bearer token.

One design choice stands out: the registration engine itself is configured with a single HTTP proxy URL. If you need chained egress, such as node-then-home-broadband, the README says to configure that in the proxy client (its example is mihomo dialer-proxy), transparent to the engine. That keeps the engine simple and pushes chaining to a component that already does it well. It also means the engine cannot report on a chain it does not know about, which is why the traffic metering exists as a separate local layer.

Batch traffic metering inserts a temporary local-only metering layer in front of the existing HTTP proxy and shows upstream, downstream and total for the batch. The README states it does not store proxy addresses or credentials. That is a sensible boundary: you get volume numbers without the panel becoming a second copy of your proxy inventory.

## Installing grok-register-panel and running a first batch

The README lists Python 3.10+ and network access to the registration page, the temporary mailbox API and auth.x.ai. Linux and macOS are formally supported; Windows is described as locally verified with CI covering Node and Xvfb resolution. The install sequence is short, but one step is easy to skip and the README warns about it: pip install only installs Python dependencies, and without camoufox fetch the browser will not start.

```bash
git clone https://github.com/lij768423-svg/grok-register-panel.git
cd grok-register-panel

python3 -m venv .venv
source .venv/bin/activate

pip install -r requirements.txt
python -m camoufox fetch

cp config.example.json config.json
```

On Windows the README offers a one-command path so you do not have to SSH into Linux. Note the warning attached to it: point the proxy at a URL reachable from the Windows host, not the 127.0.0.1:82xx mixed port you may have used on Linux.

```powershell
powershell -ExecutionPolicy Bypass -File scripts\setup_windows.ps1
powershell -ExecutionPolicy Bypass -File scripts\run_windows_batch.ps1 -Count 1 -Workers 1
powershell -ExecutionPolicy Bypass -File scripts\run_windows_panel.ps1
```

Then edit config.json. The fields that matter first are email_provider, proxy, register_workers, register_count, cpa_auto_add and cpa_auth_dir. The README suggests starting with 2 to 3 workers. The panel's write endpoints require MONITOR_TOKEN, and the README is explicit that start, stop and control return 401 when it is unset, so set it before you expose anything.

MONITOR_HOST defaults to 127.0.0.1, MONITOR_PORT defaults to 8787, and per the README binding failure does not fall back to 0.0.0.0. That is the correct default for a panel that can start browser processes. If you set the host to a public interface, the token is the only thing between the internet and your task control API.

## Where the design gets opinionated: ASN prechecks, early stop, and BFS

Three mechanisms separate this fork from a plain registration script.

First, egress precheck. Before a run, the engine resolves the exit IP and ASN, and rotates the exit when it matches the blacklist. The orchestrator can also extend that blacklist automatically, with rules written to a JSON state file rather than patched into source. BLACKLIST_STATE_FILE defaults to ./log/blacklist_state.json. Keeping rules in state rather than code is the right call for a tool that runs unattended: you can inspect and edit what the engine learned without touching Python.

Second, risk-control early stop. When botFlagSource=1 and policy=deny, the engine skips the remaining OAuth steps instead of retrying into a wall. Anyone who has watched a registration loop burn proxies on a flow that is already denied will recognize why this matters. The related SSO risk panel reads botFlagSource and policy=deny from grok.com using existing SSO credentials without swapping tokens, and the README says the panel exports only a redacted status list with no credentials in it.

Third, BFS detection. The engine decodes access_token and SSO JWTs and checks for a bfs claim, which the README describes as independent of botFlag. Registered accounts get flagged automatically, and the panel can scan the CPA inventory in bulk. Independent signals are useful because they disagree: an account can look clean on one check and fail the other.

## Real limits: headless Linux, Windows path traps, and a panel that is not a security boundary

The support matrix is honest and worth taking at face value. Linux container deployments must keep procfs mounted, usually the default /proc, because the panel uses it to find and safely stop the current project's task processes. Strip that mount and the stop path has nothing to work with. Headless Linux depends on xvfb-run, which the panel invokes when there is no display session; GROK_USE_XVFB=auto only enables it on Linux without a display, and the README documents 1 and 0 as forced on and direct start.

Windows has its own traps. The README explicitly says not to point PLAYWRIGHT_NODEJS_PATH at scripts/playwright-node, because that is a bash wrapper; the runtime resolves node.exe or Playwright's bundled Node and injects EPIPE protection through a quoted NODE_OPTIONS --require. Proxies must be reachable from the Windows host. Copying a Linux config across is a predictable failure.

The panel itself is a control plane, not a hardened multi-tenant service. The README notes that PANEL_INCLUDE_TAIL defaults to 0 because enabling it attaches raw log tails to the status endpoint, and those may contain sensitive data. The stated security posture is owner-only permissions on proxies, accounts, SSO, logs, auth and runtime state. That is file-level hygiene. It does not make the HTTP surface safe to publish, and the README does not document rollback for a batch that has already written auth files.

## Alternatives and how they differ

The direct alternative is the upstream project this fork is based on, AaronL725/grok-register. The difference is scope, not approach. Upstream is the registration flow; this repository keeps that flow and adds an orchestrator, a proxy pool with liveness checks and cooldowns, an email domain pool with provider binding and automatic blacklisting after repeated rejections, an SSO risk panel, BFS scanning and a web control surface. If you only need to run the flow once from a shell, upstream is the smaller thing to read. If you need to watch success rate over time and rotate egress without editing config between runs, the panel is the reason to pick this fork.

A second comparison is to Camoufox itself. Camoufox is the anti-detect browser layer, and this project depends on it rather than replacing it. Choosing Camoufox directly means writing your own registration flow, mailbox integration and retry policy. Choosing this project means accepting its opinions about concurrency, blacklisting and where state lives.

The third alternative is not a tool at all: using Grok through its normal client. That path needs no Camoufox fetch, no proxy pool and no MONITOR_TOKEN, and it is the correct answer for the vast majority of people asking whether they can use Grok on a computer or in a browser.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-18, the same day as the v0.4.4 release. Releases v0.4.1 and v0.4.2 landed a week earlier, on 2026-08-11. That is a recent, closely spaced release cadence, but the cadence is the fact, not a promise about the next release.

The licence is MIT, and the repository carries both LICENSE and a LICENSES/ directory plus a NOTICE file, which is what you would expect for a fork that credits AaronL725/grok-register. MIT is permissive; if you redistribute, keep the copyright and permission notice with the code. Whether your use of the registration flow itself is permitted is a separate question governed by xAI, mailbox and proxy provider terms, and the README's disclaimer says so directly. That is not a legal opinion, and this article is not one either.

The upgrade cost is mostly environmental. requirements.txt pins exact versions, including DrissionPage==4.1.1.4, curl_cffi==0.13.0, camoufox[geoip]==0.5.4, playwright==1.60.0 and psutil==7.2.2, and there is a requirements.lock.txt alongside it. A Camoufox or Playwright bump can require re-running python -m camoufox fetch and re-testing the Node resolution path on Windows. There is a CHANGELOG.md, a RELEASE_CHECKLIST.md and a VERSION file, so the project tracks its own releases rather than leaving you to diff commits.

## Conclusion

Adopt it if you already run an authorized registration lab with your own mail domains, proxies and Python 3.10+, and you want the run state, proxy pool and BFS checks in one panel. Do not adopt it if you want a normal way to sign in to Grok, if you cannot run camoufox fetch, or if you expect the panel to be reachable without setting MONITOR_TOKEN. Before your first batch, verify that camoufox fetch completed, that MONITOR_TOKEN is set, and that config.json points cpa_auth_dir at the directory you actually want written.

## FAQ

### Do you have to register to use Grok?

This project does not answer that question about Grok itself; it is a tool for automating the registration flow, and its README frames that use as automated-flow research, own-environment integration and personal study. If you want to use Grok as a product, this repository is not the path.

### How do you access Grok?

The README does not describe a way to access Grok as an end user. It describes a registration chain (email OTP, profile page, Turnstile, SSO, Device or OAuth) that writes credentials into cpa_auth/ or grok2api_auth/.

### Can I access Grok on my computer?

Not through this project in the sense of chatting with Grok. What runs on your computer is the Camoufox registration engine and the webui/monitor panel on port 8787, which needs MONITOR_TOKEN set for its write endpoints.

### Can I use Grok on my browser?

The project does not document a browser client for Grok. Its browser dependency is Camoufox, which the README describes as the anti-detect browser that drives the registration flow.

## Sources

- [Official documentation](https://lij768423-svg.github.io/grok-register-panel/)
- [Official README](https://github.com/lij768423-svg/grok-register-panel#readme)
- [Project repository](https://github.com/lij768423-svg/grok-register-panel)
- [Release notes](https://github.com/lij768423-svg/grok-register-panel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lij768423-svg-grok-register-panel