GitHub-facing audit and recommended presentation for codex-multi-auth.
- Purpose: add a local multi-account OAuth manager and
codex auth ...workflow to the official@openai/codexCLI - Target users: individual developers using the Codex CLI who want explicit account switching, health checks, local recovery tooling, and optional project-scoped account pools
- Not the target: commercial multi-user services, generic API users, or teams looking for a hosted auth layer
Developers looking for a tool like this are likely to search for:
- codex cli multi account
- codex auth manager
- chatgpt oauth codex cli
- codex account switching
- codex cli auth recovery
- codex cli terminal dashboard
- codex multi account oauth
- project scoped codex accounts
These terms belong naturally in the README intro, feature list, and package metadata. They should not be stuffed into every heading.
Use this as the GitHub repository description:
Multi-account OAuth manager and codex auth wrapper for the official @openai/codex CLI, with switching, health checks, and recovery tools
- codex
- codex-cli
- openai
- chatgpt
- oauth
- oauth2
- pkce
- multi-account
- cli
- terminal-ui
- typescript
- nodejs
- developer-tools
- authentication
- account-switching
- diagnostics
- recovery-tools
- productivity
Useful badges:
- npm version
- CI status
- license
Avoid vanity badges unless they add real trust or decision value.
Use a clean text-first image with:
- project name:
codex-multi-auth - tagline:
Multi-account OAuth for the official Codex CLI - a simple visual of
codex auth login -> list -> switch -> check - terminal-inspired styling rather than abstract marketing graphics
The image should immediately communicate:
- this is a CLI tool
- it works with the official Codex CLI
- it helps manage multiple accounts
- They understand the value in one screen: it gives the official Codex CLI explicit multi-account management.
- The quick start is short and credible.
- The project sounds honest about what it is and what it is not.
- Recovery and troubleshooting commands are visible, which increases trust.
- Docs answer common adoption questions without sending the reader through maintainer-only material.
- The README reads like a command dump before it explains the product.
- The wrapper-versus-plugin distinction is unclear.
- Stale release pointers make the repo look unmaintained.
- First-run instructions are longer than they need to be.
- Governance exists, but standard community files or links are missing.
README.mddocs/getting-started.mddocs/README.mddocs/index.mddocs/features.mddocs/troubleshooting.mddocs/faq.mddocs/architecture.mdCODE_OF_CONDUCT.mdCHANGELOG.md
Before:
- README opened with operational detail before the product explanation
- plugin and wrapper roles were blurred
- release pointers were stale
- FAQ and short public architecture pages were missing
After:
- README opens with what the project is, why it exists, and how to start quickly
- the wrapper-plus-manager use case is primary, with plugin mode clearly positioned as optional
- public docs have a simpler path from install to FAQ to architecture to troubleshooting
- release and metadata guidance is explicit and current