# dou-jiang/codex-console: bulk OpenAI account automation, documented plainly

> A Python web console that forks an upstream account manager to batch register OpenAI accounts, bind payment cards and push credentials to a relay service.

**dou-jiang/codex-console** — codex-console is an integrated console project supporting task management, batch processing, data export, automatic uploads, log viewing and packaging support.

- Repository: https://github.com/dou-jiang/codex-console
- Stars: 2,235 · Forks: 982
- Language: Python
- License: MIT
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/dou-jiang-codex-console

## What the console is built to do

The project description, originally written in Chinese, calls codex-console an integrated console supporting task management, batch processing, data export, automatic upload, log viewing and packaging. The pyproject.toml gives the same project the shorter English description OpenAI account management console.

The README is more direct about the goal. This is a continuously fixed and maintained enhanced version based on cnlimiter/codex-manager, and the stated objective is to fill in the holes in the recent OpenAI registration path, the ones that worked yesterday and fail today, so that registration, login, obtaining a token, uploading, task scheduling, payment related capabilities and packaging all work more reliably.

So the feature set resolves into a pipeline. Register accounts in bulk, solve the Sentinel proof of work challenge, wait for and parse email verification codes, complete login to obtain a token, check subscription status, bind a payment card, then upload or export the credentials so another system can consume them. The v1.1.2 release adds a card pool and automatic card binding, an Auto Team backend with a management page, New-API service configuration for single account, batch and post registration upload, and a unified task center covering registration, payment, self check and Auto Team status. A scheduled task system allows creating, editing, enabling, disabling and immediately running jobs.

None of that is hidden in the documentation, which is unusual and worth noting on its own.

## A fork chasing an upstream that moves

The v1.0 notes are the clearest statement of the project's actual engineering problem. Entry one adds Sentinel POW solving logic, because OpenAI now enforces a Sentinel proof of work check and passing an empty value no longer works. That is a deliberate circumvention of an anti-automation control, and it is the first item in the release notes rather than buried in a commit.

Entry two splits registration from login. Because OpenAI's flow changed so that a completed registration no longer returns a usable token and instead redirects to a phone number binding page, the fork registers first and then runs a separate login pass to obtain the token. Entry three removes a duplicate verification email send, because the server now sends the code itself and sending a second one causes old and new codes to collide. Entry four fixes the page transition logic on re-login after the flow changed again.

The v1.1 and v1.1.1 notes follow the same pattern of chasing upstream behavior changes: fixing registration stalls caused by Outlook and temporary mailboxes not receiving messages, restoring subscription status checks, fixing six digit strings being misread as verification codes, fixing case sensitivity that made Outlook.com addresses look unregistered, and improving OAuth token refresh compatibility for one time token scenarios.

This is a maintenance treadmill with a floor under it. Each entry represents a fix that upstream will eventually re-break, which is a fair characterization of any automation built against a target that actively detects it.

## The dependency list is the architecture

The pyproject.toml declares a project named codex-console at version 1.1.2, requiring Python 3.10 or later, and the dependency list is short enough to read as a design document.

```toml
[project]
name = "codex-console"
version = "1.1.2"
description = "OpenAI account management console"
requires-python = ">=3.10"
dependencies = [
    "curl-cffi>=0.14.0",
    "fastapi>=0.100.0",
    "uvicorn>=0.23.0",
    "jinja2>=3.1.0",
    "python-multipart>=0.0.6",
    "pydantic>=2.0.0",
    "pydantic-settings>=2.0.0",
    "sqlalchemy>=2.0.0",
    "alembic>=1.13.0",
    "aiosqlite>=0.19.0",
    "psycopg[binary]>=3.1.18",
    "websockets>=16.0",
    "path>=17.1.1",
]
```

Two dependencies explain most of the rest. curl-cffi is a Python binding for libcurl-impersonate, which lets a client present the TLS and HTTP fingerprints of a real browser, and that is what makes automated requests to a signup endpoint look like a browser to the server. curl-cffi is not an accident of the dependency list; it is the point.

The remainder is an ordinary FastAPI service: Jinja2 for templates, Pydantic and pydantic-settings for validation and configuration, SQLAlchemy with aiosqlite and psycopg for either SQLite or PostgreSQL storage, Alembic for schema migrations, and websockets for live progress. requirements.txt lists essentially the same set with uvicorn standard extras and playwright added, which tells you a headless browser is available for the pages that require one. The project also declares a hatchling build backend, a console script entry point pointing at webui main, and a dev extra with pytest and httpx, plus a payment extra holding playwright.

## A browser you can watch through a VNC port

The Dockerfile in this repository is the piece that explains why the project needs a display server at all. It starts from python:3.11-slim and installs a specific set of system packages: gcc and python3-dev to build native wheels, then xvfb, fluxbox, x11vnc, websockify and novnc.

That combination is a virtual framebuffer with a window manager, a VNC server, and a web based VNC client. The intent is stated in the docker-compose file, which sets DISPLAY to :99, enables VNC on port 5900 and noVNC on port 6080, and raises the shared memory allocation to one gigabyte so Chromium has room to run. A commented line in the compose file notes that port 5900 can be opened if you want to connect a VNC client directly.

The point of that stack is the semi-automatic card binding mode introduced in v1.1. The release note is candid about its limit: 3DS cannot be skipped and must be completed through the actual flow. Everything before the 3DS challenge, address generation and form filling, is automated in a real browser that a human can watch and intervene in over noVNC. This is a design decision about where to put the human in the loop, and it sits right at the boundary where the tool stops being a script.

For an architecture review, the takeaway is that this is a browser automation project wearing a web console, and the Docker image is sized accordingly.

## Storage, uploads and the two supported databases

The console persists its accounts, credentials and payment history in SQLAlchemy, and the v1.1.2 release adds Alembic as a proper migration system plus a set of tests and CI workflows. The earlier releases had been relying on a lighter approach, and v1.1.1 describes a lightweight field migration at startup that automatically fills in newly added columns to ease upgrades from older data.

Database choice is a runtime decision rather than a build time one. aiosqlite is in the dependency list for a local file, and psycopg with the binary extra is there for PostgreSQL. The README documents setting APP_DATABASE_URL to a postgresql connection string when running against a remote database, while noting that DATABASE_URL is also accepted at lower priority. The compose file mounts a data directory and a logs directory so the database and logs survive a container restart, which is the single most common way a deployment like this loses its data.

The credential export side is where the pipeline is designed to hand off. v1.1 added a Codex account export format for later login, migration and import. v1.1.1 added a newApi upload target so a configuration can select which import target type to use, and added proxy_url support in the CPA authentication file so a proxy address can be stored and reused. v1.1.2 extended uploading to single account, batch, and automatic post registration upload, and added the card pool with automatic card binding and upstream integration.

In other words the accounts are not the endpoint. They are inventory to be moved somewhere else.

## The question this repository leaves open

The v1.1.1 release notes changed the announcement area to fixed text and fixed links, with an explicit message about being permanently free and open source, about reselling being prohibited, and asking paying users to request a refund. That is a small entry in a changelog and a large statement about intent.

OpenAI's terms do not permit creating accounts in bulk through automated means, and they do not permit reselling access. A tool whose documented purpose is batch registration, proof of work circumvention, and card binding at up to 1000 accounts per batch, where the batch limit was raised from 100 to 1000 in v1.1.1, is built for one kind of operation. This article does not need to speculate about what that operation is, but it is fair to name the tension: the README advertises free and open source with resale prohibited, which tells you the author knows the downstream use is the variable.

There is a legitimate reading too. Teams that need many accounts for testing, and researchers studying signup flows, are real use cases. But neither of those needs a card pool, a VNC bridge into a live payment form, or a newApi relay target, and the presence of those features makes the intended workload clear enough that an article should say so rather than write around it.

The engineering is competent and frequently skilled. Migrating to Alembic, adding controlled concurrency to batch verification, and adding real tests and CI are all signs of a serious maintainer. Serious maintenance of a tool built against a target that detects automation is still maintenance of that tool, and the repository should be read with both facts in view.

## Conclusion

Read the repository name and the feature list together and there is no ambiguity about what this project does. It automates the creation of OpenAI accounts in bulk, binds payment cards to them semi-automatically, solves the Sentinel proof of work challenge the registration flow now requires, and exports the resulting credentials to a relay endpoint. That is the product. Everything else in the repository, the FastAPI web UI, the SQLite and PostgreSQL support, the Alembic migrations, the task center, the scheduled jobs and the noVNC browser view, is engineering built around that one purpose. The fork relationship explains the release pattern better than anything else: v1.0 landed on 25 March 2026, v1.1 the next day, v1.1.1 on 26 March, and v1.1.2 on 31 March, with nearly every entry describing a registration flow that broke because something upstream changed. A 2,239 star and 985 fork repository where 74 issues remain open is a project with a specific audience, and the audience is people running account operations at volume. Whether that is legitimate depends on a question this repository does not answer, which is whether the operator has permission from OpenAI to create the accounts being created. The dependency list makes the technical approach clear, and this article stops short of describing how to run it.

## FAQ

### What is this project built on?

It is a Python 3.10 or later application using FastAPI and uvicorn with Jinja2 templates, Pydantic for validation and settings, SQLAlchemy with aiosqlite or PostgreSQL for storage, Alembic for migrations, and websockets for progress updates. `curl-cffi` is included so outgoing requests can present browser-like TLS fingerprints, and playwright is available for pages that need a real browser.

### How does it relate to codex-manager?

It is a fork. The README states the repository is based on cnlimiter/codex-manager and credits the upstream author, describing itself as a continuously fixed and maintained enhanced version that makes compatibility fixes, flow adjustments and experience improvements on top of the original structure.

### Which databases does the console support?

Both SQLite and PostgreSQL, through SQLAlchemy. The dependency list carries `aiosqlite` for a local file and `psycopg[binary]` for PostgreSQL, and the README documents setting `APP_DATABASE_URL` to a postgresql connection string for a remote database, while noting that `DATABASE_URL` is also accepted at lower priority.

## Sources

- [dou-jiang/codex-console on GitHub](https://github.com/dou-jiang/codex-console)
- [Issues](https://github.com/dou-jiang/codex-console/issues)
- [License: MIT](https://github.com/dou-jiang/codex-console/blob/main/LICENSE)
- [README](https://github.com/dou-jiang/codex-console/blob/main/README.md)
- [Releases](https://github.com/dou-jiang/codex-console/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dou-jiang-codex-console