poxiaoxi博客同时使用多个经过授权的 Codex 账号时，真正麻烦的往往不是登录，而是后续管理：哪个账号还有额度、某个请求实际用了哪个账号、不同客户端应该填写什么地址，以及怎样避免把登录凭据分散到多个工具中。
CodexManager 把这些工作集中到了一个管理界面里。它既能整理账号和用量，也能在本机运行网关，让 Codex CLI、Claude Code、Gemini CLI 或其他兼容客户端通过统一地址发起请求。
它不是新的 Codex 客户端
CodexManager 是第三方开源项目，并非 OpenAI 官方产品。它的主要职责不是替代 Codex 编写代码，而是管理 Codex 账号、平台 Key、模型路由和请求转发。
项目采用“桌面界面加本地服务”的设计。桌面端负责账号、配置和日志管理，后台服务处理授权、用量刷新以及网关请求。用户仍然可以继续使用原来的 Codex CLI，只是将 API 地址和平台 Key 指向 CodexManager。
从技术结构看，项目后端主要使用 Rust，桌面端基于 Tauri，管理界面使用 Next.js 和 React，数据默认保存在本机 SQLite 数据库中。
账号池解决哪些问题
账号管理页可以集中导入、导出和整理账号，并通过浏览器授权或 Device Code 完成 chatgpt.com 登录。授权回调失败时，也可以手动粘贴回调地址进行解析。
账号可设置分组、标签、排序和备注，界面会显示账号状态、剩余额度及重置时间。项目目前能够处理常见的 5 小时、7 日窗口，以及部分附加额度窗口。
这里的账号池并不意味着所有请求都会随意切换账号。网关会结合账号状态、可用额度、并发限制、路由模式和平台 Key 绑定范围筛选候选账号。项目文档还说明，当前行为正在向“会话绑定账号”的方向调整，不能把它简单理解成每次请求都随机换号。
平台 Key 与登录凭据要分开
CodexManager 可以随机生成或自定义平台 Key。外部客户端连接本地网关时，应该使用这种平台 Key，而不是把账号的 access token、refresh token 或登录 Cookie 直接写进客户端配置。
例如本机默认服务地址为：
http://localhost:48760/v1
在 Codex CLI 的配置中，可以把它设为自定义模型提供方的 Base URL，再将平台 Key 写入对应的 auth.json。这样，客户端只接触网关凭据，具体账号由 CodexManager 在后台管理。
平台 Key 还可以绑定模型、推理等级、服务等级和指定账号分组。对于需要把测试账号、个人账号或不同用途账号分开管理的用户，这比在多个配置文件中反复替换 Token 更清晰。
本地网关能接入哪些工具
项目提供 OpenAI 兼容入口，可供 Codex CLI、Gemini CLI、Claude Code 及其他兼容工具使用。当前网关覆盖 Responses、Chat Completions、Messages、SSE 流式传输、工具调用、MCP 和 Skills 等链路。
它还包含图片生成兼容入口，可将相关 Images 请求转换到内部的 Responses 与 image_generation 工具链。具体模型是否可用，仍取决于上游账号权限、模型目录和项目配置。
除了本地账号池，CodexManager 还可以管理第三方聚合 API，并在模型目录中配置不同路由。不过项目不会自动读取供应商的模型池，路由和上游模型名称需要由管理员明确设置。
Skills 与插件分别管理
CodexManager 将 Skills 安装和 Codex 插件安装分成两个区域，避免把两种机制混在一起。
Skills 可以从内置或自定义 GitHub 仓库安装，也支持 skills.sh 搜索、ZIP 文件和本地目录导入。用户可以刷新技能仓库、单独安装某个 Skill，并管理已经安装的内容。
Codex 原生插件则继续使用 Marketplace 的完整安装流程。项目中的系统级 Skill 保持只读，避免管理操作直接改写内置内容。
桌面端还提供项目收藏与启动入口，可以选择本机目录，在新终端中启动 Codex，或者打开当前项目的 resume 会话选择器。Web 和 Docker 版本无法直接访问用户电脑上的项目目录，因此没有完全相同的本地项目能力。
桌面端和 Service 怎么选
| 运行方式 | 主要特点 | 更适合的场景 |
|---|---|---|
| 桌面端 | 本地界面、自动启动服务、可访问本机项目目录 | 个人开发和日常 Codex CLI 管理 |
| Service 版 | 独立运行 service 与 Web 管理页面 | 无桌面环境或需要浏览器管理 |
| Docker | 支持单容器或双容器部署，数据写入持久卷 | 服务器部署和团队内部使用 |
桌面端启动后，点击“启动服务”即可进入账号授权和用量管理。Service 版本提供 codexmanager-service、codexmanager-web 和一键启动程序，默认服务端口为 48760，Web 管理页面端口为 48761。
Docker 模式下，管理页面和兼容网关可以统一从 48761 端口进入。部署在远程服务器时，客户端应填写实际可访问的服务器地址，不能继续使用容器内部的 localhost。
平台兼容仍有现实差异
项目提供桌面端和 Service 构建，并准备了 Docker 部署方案。不过作者在 README 中明确说明，目前主要保证 Windows 桌面端的可用性，其他平台缺少足够测试环境，遇到问题可能需要用户自行验证并提交 Issue。
macOS 发布包目前也没有使用 Apple Developer 账号完成公证，首次运行可能被 Gatekeeper 拦截。官方文档提供了移除隔离属性的放行方式，但执行前应确认安装包确实来自项目官方 Release。
因此，“支持多个平台”和“每个平台已经得到同等程度验证”是两回事。准备在生产环境使用 Service 或非 Windows 桌面端时，先在隔离环境中测试会更稳妥。
不要忽略账号与网关安全
CodexManager 会处理账号 Token、平台 Key、RPC Token 和请求日志，这些内容都属于敏感数据。默认服务监听 localhost，相对适合单机使用；一旦改为 0.0.0.0，或者通过反向代理开放到局域网和公网，就需要额外设置 Web 强密码、访问控制和网络边界。
数据库默认保存在系统应用数据目录中，桌面端文件名为 codexmanager.db。备份和迁移数据库时，应把它视为敏感文件，不要上传到公开网盘或代码仓库。
提交故障日志和截图前，也要清除 Authorization、Cookie、access token、refresh token、RPC Token 和平台 Key。项目本身并不承诺为公网部署提供全自动安全加固，部署者仍需负责服务器和反向代理的安全配置。
精彩评论