Two local ports separate proxy traffic from OAuth callbacks
The Docker quick start publishes 2 ports: 2455 for the dashboard and proxy, and 1455 for browser OAuth callbacks. After an operator adds ChatGPT accounts, Codex CLI can send Responses traffic to /backend-api/codex; OpenCode and ordinary SDK clients use the /v1 surface.
This architecture turns several account sessions into shared infrastructure. codex-lb refreshes upstream models, maps OpenAI-style requests, handles streaming, records usage, and selects an account that can serve the request. With one account, the proxy creates more state and more places for authentication, networking, or continuation data to fail.
Eight routing strategies cannot make every thread portable
The routing guide documents 8 strategies, including capacity weighted, relative availability, round robin, fill first, and single account. The recommended low-volume starting points prefer available capacity while retaining sticky threads. The guide says no strategy can guarantee account-safety outcomes. Operators remain responsible for OpenAI's terms, normal request volumes, and traffic patterns appropriate to their accounts.
Sticky routing is only a preference. A Codex continuation tied to a stored response, conversation, turn state, or uploaded file has hard affinity to its owning account. Turning off sticky threads does not remove that binding. If the owner becomes unavailable, an old thread can fail while a fresh one routes normally.
What happened when we ran it
Our measurement setup installed 99 packages in 41 seconds and used 185 MB on disk. The build succeeded in 10 seconds. Tests exited with code 4 after 6 seconds, before collection, because tests/conftest.py imported pytest_asyncio and Python reported ModuleNotFoundError: No module named 'pytest_asyncio'. The log does not establish why the module was absent.
Pip-audit found 0 known vulnerabilities in the installed Python packages. commit 5ad638b occupied 47 MB before dependencies, with 4,848 files and about 592,059 source lines. Our scan found 10 CI workflow files, a Dockerfile, a Compose file, and a tests directory. The failed bootstrap means the checkout has no passing test result from our stated 3-CPU, 8 GB sandbox.
Three dashboard modes still need a deliberate remote boundary
codex-lb offers 3 dashboard authentication modes: password with optional TOTP, a trusted reverse-proxy header, or disabled authentication. The standard mode is the default. First-time remote setup requires a one-time bootstrap token. Trusted-header mode accepts identity only from configured proxy CIDRs; disabled authentication is documented for externally restricted deployments.
API-key authentication is disabled by default for local proxy traffic. Non-local requests are rejected until it is configured, and /v1/usage always requires a valid key. Remote deployment also needs WebSocket upgrades forwarded and trusted proxy ranges set correctly. Exposing port 2455 directly would put account-backed model access behind assumptions meant for localhost.
One data directory holds the database and encryption material
The documented backup target is 1 data directory: ~/.codex-lb/ locally or /var/lib/codex-lb/ in Docker. It contains the database, encryption key, and archives. SQLite needs no configuration. PostgreSQL is optional; the Compose guide uses Postgres 18 and gives a guarded upgrade path for version 16 volumes.
Replicas need the same encryption key so the first-run bootstrap token survives restarts across instances. Database, API keys, account sessions, and usage history make this service a high-value internal target. Backups should protect confidentiality and availability, and operators should restore-test them before relying on the dashboard as their only account inventory.
A 24-hour telemetry cycle is active before opt-out
The service sends 1 anonymous snapshot at startup and every 24 hours while telemetry is active. Its schema includes a random instance ID, platform details, deployment shape, bucketed account counts, and seven-day usage aggregates. The project says it excludes emails, workspace IDs, client IPs, API keys, request and response content, custom model names, and free-text errors.
The dashboard shows the envelope, yet telemetry runs before a saved decision unless the environment override disables it. Setting CODEX_LB_TELEMETRY_ENABLED=false prevents a connection. A dashboard switch from active to inactive sends 1 signed opt-out notice; the environment kill switch does not. Strict outbound rules should set the variable before first launch.
Three open issues affect stalls, threads, and port 1455
Three current issues deserve a trial plan. Issue 2029 keeps historical minute-long stalls open because its investigation did not establish the full cause. Issue 1921 reports a version 1.23.0 thread repeatedly failing with an invalid previous_response_id. Issue 2076 says an expired dashboard OAuth flow on port 1455 can intercept a later Codex Desktop callback.
The reports map to the proxy's hardest state: event-loop load, durable account ownership for continuations, and callback-port lifetime. Run long conversations, account failures, restarts, and simultaneous desktop login in staging. A healthy dashboard and a fresh request are too narrow to prove that old threads recover cleanly.
September 6 activity comes with 140 open items
GitHub recorded 2,977 stars, a last push on September 6, 2026, and 140 combined open issues and pull requests. Release v1.24.0 arrived on August 26 with many proxy, dashboard, database, and telemetry changes. The queue shows how many edge cases appear when account affinity, streaming transports, several clients, and two database backends meet.
codex-lb is for an operator who can own those edges. The 10-second build and 0 known vulnerabilities are encouraging, while the missing pytest plugin leaves the measured checkout short of a green test run. Start with one client, explicit API-key authentication, telemetry decided in environment configuration, and a backed-up data directory. If pooling is optional, direct Codex is easier to trust.