CodexBar CLI 配置命令完全指南provider 开关、API Key 存储与隔离配置文件【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar本指南以 CodexBar 的codexbar config命令族为核心讲解如何在不打开图形设置界面的前提下通过命令行管理 provider 启停、写入 API Key、创建隔离配置文件并完成配置校验与成本历史窗口的临时覆盖。读完本文你将掌握一套可用于脚本与 CI 的完整配置工作流并理解 CLI 与 App 共享同一份解析后配置文件的底层机制。定位CLI 与 App 共享同一份解析配置codexbar config编辑的并不是一份独立的 CLI 配置文件而是与 App 的Settings → Providers 面板完全相同的解析后配置文件。CLI 入口通过CodexBarConfigStore完成加载与保存见 Sources/CodexBarCore/Config/CodexBarConfigStore.swift因此你在终端里做的任何修改都会立刻反映到菜单栏 App 的 provider 列表、开关状态与 API Key 存储中反之亦然。配置文件路径解析优先级配置文件的具体位置由CodexBarConfigStore.defaultURL(home:environment:fileManager:)决定解析优先级如下实现见 CodexBarConfigStore.swiftCODEXBAR_CONFIG环境变量若设置且非空则直接以其值作为配置文件路径支持~展开拥有最高优先级绝对路径的XDG_CONFIG_HOME若设置且为绝对路径使用XDG_CONFIG_HOME/codexbar/config.jsonXDG 默认路径~/.config/codexbar/config.json——新安装默认使用遗留路径~/.codexbar/config.json——当 XDG 默认路径不存在而遗留路径存在时已有安装继续沿用旧文件。由此可以看出兼容策略新安装默认写入~/.config/codexbar/config.json老安装只要没有 XDG 配置就继续使用~/.codexbar/config.json两种路径都受支持。写入安全0600 文件权限配置文件可能包含 API Key、Cookie 头等敏感凭据因此CodexBarConfigStore.saveEncodedData(_:)在写入时使用.atomic选项并通过applySecurePermissionsIfNeeded()将文件权限强制设为0600仅当前用户可读写见 CodexBarConfigStore.swift 与 L125-L131。注意CODEXBAR_CONFIG覆盖对当前进程环境的读写同时生效——CLI 的每次读取与保存都会经过CodexBarConfigStore()默认初始化而该初始化内部即调用defaultURL(environment:)从进程环境解析路径见 CLIHelpers.swift 的loadConfig。Providers持久化的 provider 开关管理列出 provider 启停状态codexbar config providers codexbar config providers --json --pretty文本输出形如grok: enabled (Grok)、cursor: disabled (Cursor)default标记表示该 provider 的默认启用状态来自其元数据JSON 输出则返回包含provider、displayName、enabled、defaultEnabled四个字段的ConfigProviderStatusResult数组见 CLIConfigCommand.swift。启用与禁用codexbar config enable --provider grok codexbar config disable --provider cursorrunConfigSetProviderEnabled(_:enabled:)先通过ProviderDescriptorRegistry.cliNameMap将--provider参数不区分大小写解析为正式的 provider 标识再写入配置见 CLIConfigCommand.swift。若提供未知 provider 名称命令会以失败退出码报错Unknown or missing provider. Use --provider name.。与usage --provider的本质区别这两个机制完全不同codexbar config enable/disable是持久化设置会写入配置文件影响 App 与后续所有 CLI 调用codexbar usage --provider grok是单次命令覆盖只对这一次抓取生效不编辑任何配置。全部 provider 被禁用时的行为如果所有 provider 都被禁用codexbar usage不带--provider文本模式不输出任何内容codexbar usage --json输出[]显式传入--provider name仍然只为该次命令抓取对应 provider。这一行为由runUsage中 provider 列表的生成逻辑决定不带--provider时使用的 provider 集合来自配置中启用的 providerCodexBarConfig.enabledProviders()见 CodexBarConfig.swift空集合即得到空输出。API Keys命令行安全写入凭据API Key 存储在配置文件的 provider 条目下providers[].apiKey。推荐通过标准输入管道传入密钥避免密钥出现在 shell 历史与进程列表中printf %s $ELEVENLABS_API_KEY | codexbar config set-api-key --provider elevenlabs --stdin只存 Key、不启用 providerset-api-key默认会顺带启用该 provider若只想保存密钥加--no-enableprintf %s $OPENROUTER_API_KEY | codexbar config set-api-key --provider openrouter --stdin --no-enable常用示例汇总printf %s $OPENAI_ADMIN_KEY | codexbar config set-api-key --provider openai --stdin printf %s $ANTHROPIC_ADMIN_KEY | codexbar config set-api-key --provider claude --stdin printf %s $DEEPGRAM_API_KEY | codexbar config set-api-key --provider deepgram --stdin printf %s $GROQ_API_KEY | codexbar config set-api-key --provider groq --stdin printf %s $LLM_PROXY_API_KEY | codexbar config set-api-key --provider llmproxy --stdin printf %s $Z_AI_API_KEY | codexbar config set-api-key --provider zai --stdin printf %s $XAI_MANAGEMENT_API_KEY | codexbar config set-api-key --provider xai --stdinz.ai 团队账号token 账户写入z.ai 团队模式需要同时携带组织与项目信息使用以下完整参数printf %s $Z_AI_API_KEY | codexbar config set-api-key --provider zai --stdin \ --label Team \ --usage-scope team \ --organization-id org_... \ --workspace-id proj_...--organization-id与--workspace-id必须为单行BigModel 组织/项目 ID源码中通过cleanSingleLineConfigValue强制校验含换行会直接报错见 CLIConfigCommand.swift传入团队参数后密钥会写入providers[].tokenAccountsProviderTokenAccountData并自动清空该 provider 的apiKey字段--label缺省时为Team见 CLIConfigCommand.swift上述 account 参数仅对--provider zai有效对其他 provider 使用会报Token-account options are only supported for --provider zai.并且--usage-scope目前仅接受team见 CLIConfigCommand.swift。团队/个人两种形态的完整配置示例与 token 来源回退顺序可参见 z.ai provider 文档。密钥输入与清洗规则resolveConfigAPIKeyInput见 CLIConfigCommand.swift要求--api-key与--stdin二选一同时给出会报错随后cleanConfigSecret会去除首尾空白、剥离一层成对的引号空值直接判为缺失。这保证了从环境变量、文件或 echo 管道进入的密钥都能被规整存储。provider 差异哪些吃 API Key、哪些不吃并非所有 provider 都接受配置型 API Key。set-api-key在执行前会通过ProviderConfigEnvironment.supportsAPIKeyOverride(for:)检查见 Sources/CodexBarCore/Config/ProviderConfigEnvironment.swift不支持时直接以失败退出例如Admin API provider如 OpenAI Platform 的openai需要具备组织/用量权限的管理密钥普通推理密钥不可用xaiprovider读取的是 xAI 开发者平台的计费数据需要 Management 密钥外加团队 ID——团队 ID 通过 provider 条目中的workspaceID字段、XAI_TEAM_ID环境变量或 App 设置面板配置推理 API Key 不被接受grokprovider与xai不同它通过自己的浏览器/CLI 会话跟踪消费者 Grok/SuperGrok 订阅不接受 API Key启用它只需codexbar config enable --provider grokcodexprovider也不支持配置 API Key报错会提示改用--provider openai见 CLIConfigCommand.swift。LLM Proxy 的额外要求base URLLLM Proxy 除 API Key 外还需要 base URL单次 CLI 运行设置环境变量LLM_PROXY_BASE_URL持久化配置在 CodexBar 配置文件的 provider 条目中加入enterpriseHost字段对应源码中的ProviderConfig.enterpriseHost见 CodexBarConfig.swift。隔离配置文件测试、演示与 CI 的推荐做法避免污染真实配置最稳妥的方式是让 CLI 指向一个临时配置文件。CODEXBAR_CONFIG覆盖对当前进程环境的读写同时生效因此可以整段执行export CODEXBAR_CONFIG/tmp/codexbar-config.json codexbar config enable --provider grok codexbar config providers --json --pretty后续所有config、usage、cost等命令在该 shell 会话中都读写这个临时文件测试结束直接删除即可。同样的机制也被仓库测试广泛使用如 Tests 目录下多个用例通过设置CODEXBAR_CONFIG指向临时路径来隔离配置状态。与makeDefault的配合空文件也能工作CodexBarConfigStore.load()在文件不存在时返回nilCLI 的loadConfig会回退到CodexBarConfig.makeDefault()见 CodexBarConfig.swift——默认配置会为每个已知 provider 生成条目因此从零开始的隔离环境也能正常运行enable、usage等命令。Cost history window成本历史窗口菜单栏 App 的本地成本历史窗口由 App 设置控制CLI 一次性报告则通过--days临时覆盖默认 30 天codexbar cost --provider codex --days 90 codexbar cost --provider claude --days 180 --format json --pretty--days接受范围为1...365 天越界值会被钳制decodeCostHistoryDays先解析参数随后max(1, min(365, parsed))保证始终落在合法区间见 CLICostCommand.swift。注意cost命令只支持本地有成本数据的 provider对不支持 provider 的请求会在 stderr 提示Skipping providers without local cost usage。Validation手改配置后的校验与检视手写或修改配置文件后用以下两条命令验证与检查codexbar config validate codexbar config dump --prettyconfig validate结构化错误报告runConfigValidate调用CodexBarConfigValidator.validate(config)见 Sources/CodexBarCore/Config/CodexBarConfigValidation.swift逐项检查后按格式输出文本模式无问题时打印Config: OK有问题时逐条打印[ERROR]/[WARNING] provider (field): messageJSON 模式输出CodexBarConfigIssue数组每条包含severitywarning/error、provider、field、code、message五个字段便于脚本解析退出码存在任何error级问题时以失败码退出否则成功——这正是 CI 门禁的理想形态。校验覆盖的典型问题见 CodexBarConfigValidation.swiftversion与当前配置版本不一致version_mismatchsource设置为该 provider 不支持的取值unsupported_source/api_source_unsupported设置了apiKey但该 provider 并不支持 api sourceapi_key_unused选择source: api却缺少 API 凭据api_key_missingcookieSource: manual却没有cookieHeadercookie_header_missingsecretKey被设置但只有 bedrock、doubao 使用该字段secret_key_unusedworkspaceID/enterpriseHost/tokenAccounts/region被设置在不适用的 provider 上workspace_unused、enterprise_host_unused、token_accounts_unused、region_unusedhooks 规则数量、重复 ID、可执行文件路径、阈值、超时等见validateHooksCodexBarConfigValidation.swift。config dump归一化配置输出dump输出的是归一化后的完整配置——包括手写文件中遗漏的 provider 条目CodexBarConfig.normalized()会补齐所有已知 provider 的默认条目见 CodexBarConfig.swift且 JSON 按键排序、pretty-print。出于安全默认会脱敏apiKey、secretKey、cookieHeader、pluginSecrets、tokenAccounts中的 token 一律替换为[REDACTED]见 CodexBarConfig.swift。如确需查看原始值使用--show-secrets来自ConfigDumpOptions见 CLIConfigCommand.swift——务必仅在可信环境使用。命令与参数速查表命令作用关键参数codexbar config providers列出 provider 启停状态--json、--prettycodexbar config enable启用 provider--provider namecodexbar config disable禁用 provider--provider namecodexbar config set-api-key写入 API Key--provider、--stdin/--api-key、--no-enable、--label、--usage-scope、--organization-id、--workspace-idcodexbar config validate校验配置并报告问题--json、--prettycodexbar config dump输出归一化脱敏配置--pretty、--show-secretscodexbar cost --days N临时覆盖成本历史窗口--days1...365、--format json、--prettycodexbar usage --provider name单次抓取覆盖不写配置--provider、--json所有命令均支持统一的输出偏好参数--format text|json、--json、--json-only、--pretty、--verbose、--log-leveltrace|verbose|debug|info|warning|error|critical。常见工作流组合CI 门禁初始化隔离配置 → 启用所需 provider → 校验 → 抓取export CODEXBAR_CONFIG/tmp/ci-codexbar.json codexbar config enable --provider grok codexbar config validate codexbar usage --provider grok --json --pretty脚本化密钥分发为多个 provider 批量写入密钥export CODEXBAR_CONFIG$HOME/.config/codexbar/config.json printf %s $GROQ_API_KEY | codexbar config set-api-key --provider groq --stdin printf %s $DEEPGRAM_API_KEY | codexbar config set-api-key --provider deepgram --stdin codexbar config validate手改配置后的安全检查codexbar config validate || echo config has errors codexbar config dump --pretty # 确认脱敏后的实际生效结构源码实现地图命令路由与各子命令实现Sources/CodexBarCLI/CLIConfigCommand.swift命令注册config子命令的validate/dump/providers/enable/disable/set-api-key定义Sources/CodexBarCLI/CLIEntry.swift配置路径解析、原子写入与 0600 权限Sources/CodexBarCore/Config/CodexBarConfigStore.swift配置模型与归一化/脱敏逻辑Sources/CodexBarCore/Config/CodexBarConfig.swift配置校验规则Sources/CodexBarCore/Config/CodexBarConfigValidation.swiftprovider 凭据支持检查Sources/CodexBarCore/Config/ProviderConfigEnvironment.swift--days解析与钳制Sources/CodexBarCLI/CLICostCommand.swiftz.ai 团队/个人配置形态docs/zai.md结语codexbar config是 CodexBar 面向脚本化运维的完整入口它与 App 共享同一份解析配置、以0600权限安全落盘、支持CODEXBAR_CONFIG隔离环境并提供结构化的校验输出与脱敏检视能力。结合cost --days的临时窗口覆盖与usage --provider的单次覆盖你可以完全绕开图形界面把 provider 管理、密钥分发与成本报告无缝嵌入日常脚本与 CI 流水线。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CodexBar CLI 配置命令完全指南：provider 开关、API Key 存储与隔离配置文件
CodexBar CLI 配置命令完全指南provider 开关、API Key 存储与隔离配置文件【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar本指南以 CodexBar 的codexbar config命令族为核心讲解如何在不打开图形设置界面的前提下通过命令行管理 provider 启停、写入 API Key、创建隔离配置文件并完成配置校验与成本历史窗口的临时覆盖。读完本文你将掌握一套可用于脚本与 CI 的完整配置工作流并理解 CLI 与 App 共享同一份解析后配置文件的底层机制。定位CLI 与 App 共享同一份解析配置codexbar config编辑的并不是一份独立的 CLI 配置文件而是与 App 的Settings → Providers 面板完全相同的解析后配置文件。CLI 入口通过CodexBarConfigStore完成加载与保存见 Sources/CodexBarCore/Config/CodexBarConfigStore.swift因此你在终端里做的任何修改都会立刻反映到菜单栏 App 的 provider 列表、开关状态与 API Key 存储中反之亦然。配置文件路径解析优先级配置文件的具体位置由CodexBarConfigStore.defaultURL(home:environment:fileManager:)决定解析优先级如下实现见 CodexBarConfigStore.swiftCODEXBAR_CONFIG环境变量若设置且非空则直接以其值作为配置文件路径支持~展开拥有最高优先级绝对路径的XDG_CONFIG_HOME若设置且为绝对路径使用XDG_CONFIG_HOME/codexbar/config.jsonXDG 默认路径~/.config/codexbar/config.json——新安装默认使用遗留路径~/.codexbar/config.json——当 XDG 默认路径不存在而遗留路径存在时已有安装继续沿用旧文件。由此可以看出兼容策略新安装默认写入~/.config/codexbar/config.json老安装只要没有 XDG 配置就继续使用~/.codexbar/config.json两种路径都受支持。写入安全0600 文件权限配置文件可能包含 API Key、Cookie 头等敏感凭据因此CodexBarConfigStore.saveEncodedData(_:)在写入时使用.atomic选项并通过applySecurePermissionsIfNeeded()将文件权限强制设为0600仅当前用户可读写见 CodexBarConfigStore.swift 与 L125-L131。注意CODEXBAR_CONFIG覆盖对当前进程环境的读写同时生效——CLI 的每次读取与保存都会经过CodexBarConfigStore()默认初始化而该初始化内部即调用defaultURL(environment:)从进程环境解析路径见 CLIHelpers.swift 的loadConfig。Providers持久化的 provider 开关管理列出 provider 启停状态codexbar config providers codexbar config providers --json --pretty文本输出形如grok: enabled (Grok)、cursor: disabled (Cursor)default标记表示该 provider 的默认启用状态来自其元数据JSON 输出则返回包含provider、displayName、enabled、defaultEnabled四个字段的ConfigProviderStatusResult数组见 CLIConfigCommand.swift。启用与禁用codexbar config enable --provider grok codexbar config disable --provider cursorrunConfigSetProviderEnabled(_:enabled:)先通过ProviderDescriptorRegistry.cliNameMap将--provider参数不区分大小写解析为正式的 provider 标识再写入配置见 CLIConfigCommand.swift。若提供未知 provider 名称命令会以失败退出码报错Unknown or missing provider. Use --provider name.。与usage --provider的本质区别这两个机制完全不同codexbar config enable/disable是持久化设置会写入配置文件影响 App 与后续所有 CLI 调用codexbar usage --provider grok是单次命令覆盖只对这一次抓取生效不编辑任何配置。全部 provider 被禁用时的行为如果所有 provider 都被禁用codexbar usage不带--provider文本模式不输出任何内容codexbar usage --json输出[]显式传入--provider name仍然只为该次命令抓取对应 provider。这一行为由runUsage中 provider 列表的生成逻辑决定不带--provider时使用的 provider 集合来自配置中启用的 providerCodexBarConfig.enabledProviders()见 CodexBarConfig.swift空集合即得到空输出。API Keys命令行安全写入凭据API Key 存储在配置文件的 provider 条目下providers[].apiKey。推荐通过标准输入管道传入密钥避免密钥出现在 shell 历史与进程列表中printf %s $ELEVENLABS_API_KEY | codexbar config set-api-key --provider elevenlabs --stdin只存 Key、不启用 providerset-api-key默认会顺带启用该 provider若只想保存密钥加--no-enableprintf %s $OPENROUTER_API_KEY | codexbar config set-api-key --provider openrouter --stdin --no-enable常用示例汇总printf %s $OPENAI_ADMIN_KEY | codexbar config set-api-key --provider openai --stdin printf %s $ANTHROPIC_ADMIN_KEY | codexbar config set-api-key --provider claude --stdin printf %s $DEEPGRAM_API_KEY | codexbar config set-api-key --provider deepgram --stdin printf %s $GROQ_API_KEY | codexbar config set-api-key --provider groq --stdin printf %s $LLM_PROXY_API_KEY | codexbar config set-api-key --provider llmproxy --stdin printf %s $Z_AI_API_KEY | codexbar config set-api-key --provider zai --stdin printf %s $XAI_MANAGEMENT_API_KEY | codexbar config set-api-key --provider xai --stdinz.ai 团队账号token 账户写入z.ai 团队模式需要同时携带组织与项目信息使用以下完整参数printf %s $Z_AI_API_KEY | codexbar config set-api-key --provider zai --stdin \ --label Team \ --usage-scope team \ --organization-id org_... \ --workspace-id proj_...--organization-id与--workspace-id必须为单行BigModel 组织/项目 ID源码中通过cleanSingleLineConfigValue强制校验含换行会直接报错见 CLIConfigCommand.swift传入团队参数后密钥会写入providers[].tokenAccountsProviderTokenAccountData并自动清空该 provider 的apiKey字段--label缺省时为Team见 CLIConfigCommand.swift上述 account 参数仅对--provider zai有效对其他 provider 使用会报Token-account options are only supported for --provider zai.并且--usage-scope目前仅接受team见 CLIConfigCommand.swift。团队/个人两种形态的完整配置示例与 token 来源回退顺序可参见 z.ai provider 文档。密钥输入与清洗规则resolveConfigAPIKeyInput见 CLIConfigCommand.swift要求--api-key与--stdin二选一同时给出会报错随后cleanConfigSecret会去除首尾空白、剥离一层成对的引号空值直接判为缺失。这保证了从环境变量、文件或 echo 管道进入的密钥都能被规整存储。provider 差异哪些吃 API Key、哪些不吃并非所有 provider 都接受配置型 API Key。set-api-key在执行前会通过ProviderConfigEnvironment.supportsAPIKeyOverride(for:)检查见 Sources/CodexBarCore/Config/ProviderConfigEnvironment.swift不支持时直接以失败退出例如Admin API provider如 OpenAI Platform 的openai需要具备组织/用量权限的管理密钥普通推理密钥不可用xaiprovider读取的是 xAI 开发者平台的计费数据需要 Management 密钥外加团队 ID——团队 ID 通过 provider 条目中的workspaceID字段、XAI_TEAM_ID环境变量或 App 设置面板配置推理 API Key 不被接受grokprovider与xai不同它通过自己的浏览器/CLI 会话跟踪消费者 Grok/SuperGrok 订阅不接受 API Key启用它只需codexbar config enable --provider grokcodexprovider也不支持配置 API Key报错会提示改用--provider openai见 CLIConfigCommand.swift。LLM Proxy 的额外要求base URLLLM Proxy 除 API Key 外还需要 base URL单次 CLI 运行设置环境变量LLM_PROXY_BASE_URL持久化配置在 CodexBar 配置文件的 provider 条目中加入enterpriseHost字段对应源码中的ProviderConfig.enterpriseHost见 CodexBarConfig.swift。隔离配置文件测试、演示与 CI 的推荐做法避免污染真实配置最稳妥的方式是让 CLI 指向一个临时配置文件。CODEXBAR_CONFIG覆盖对当前进程环境的读写同时生效因此可以整段执行export CODEXBAR_CONFIG/tmp/codexbar-config.json codexbar config enable --provider grok codexbar config providers --json --pretty后续所有config、usage、cost等命令在该 shell 会话中都读写这个临时文件测试结束直接删除即可。同样的机制也被仓库测试广泛使用如 Tests 目录下多个用例通过设置CODEXBAR_CONFIG指向临时路径来隔离配置状态。与makeDefault的配合空文件也能工作CodexBarConfigStore.load()在文件不存在时返回nilCLI 的loadConfig会回退到CodexBarConfig.makeDefault()见 CodexBarConfig.swift——默认配置会为每个已知 provider 生成条目因此从零开始的隔离环境也能正常运行enable、usage等命令。Cost history window成本历史窗口菜单栏 App 的本地成本历史窗口由 App 设置控制CLI 一次性报告则通过--days临时覆盖默认 30 天codexbar cost --provider codex --days 90 codexbar cost --provider claude --days 180 --format json --pretty--days接受范围为1...365 天越界值会被钳制decodeCostHistoryDays先解析参数随后max(1, min(365, parsed))保证始终落在合法区间见 CLICostCommand.swift。注意cost命令只支持本地有成本数据的 provider对不支持 provider 的请求会在 stderr 提示Skipping providers without local cost usage。Validation手改配置后的校验与检视手写或修改配置文件后用以下两条命令验证与检查codexbar config validate codexbar config dump --prettyconfig validate结构化错误报告runConfigValidate调用CodexBarConfigValidator.validate(config)见 Sources/CodexBarCore/Config/CodexBarConfigValidation.swift逐项检查后按格式输出文本模式无问题时打印Config: OK有问题时逐条打印[ERROR]/[WARNING] provider (field): messageJSON 模式输出CodexBarConfigIssue数组每条包含severitywarning/error、provider、field、code、message五个字段便于脚本解析退出码存在任何error级问题时以失败码退出否则成功——这正是 CI 门禁的理想形态。校验覆盖的典型问题见 CodexBarConfigValidation.swiftversion与当前配置版本不一致version_mismatchsource设置为该 provider 不支持的取值unsupported_source/api_source_unsupported设置了apiKey但该 provider 并不支持 api sourceapi_key_unused选择source: api却缺少 API 凭据api_key_missingcookieSource: manual却没有cookieHeadercookie_header_missingsecretKey被设置但只有 bedrock、doubao 使用该字段secret_key_unusedworkspaceID/enterpriseHost/tokenAccounts/region被设置在不适用的 provider 上workspace_unused、enterprise_host_unused、token_accounts_unused、region_unusedhooks 规则数量、重复 ID、可执行文件路径、阈值、超时等见validateHooksCodexBarConfigValidation.swift。config dump归一化配置输出dump输出的是归一化后的完整配置——包括手写文件中遗漏的 provider 条目CodexBarConfig.normalized()会补齐所有已知 provider 的默认条目见 CodexBarConfig.swift且 JSON 按键排序、pretty-print。出于安全默认会脱敏apiKey、secretKey、cookieHeader、pluginSecrets、tokenAccounts中的 token 一律替换为[REDACTED]见 CodexBarConfig.swift。如确需查看原始值使用--show-secrets来自ConfigDumpOptions见 CLIConfigCommand.swift——务必仅在可信环境使用。命令与参数速查表命令作用关键参数codexbar config providers列出 provider 启停状态--json、--prettycodexbar config enable启用 provider--provider namecodexbar config disable禁用 provider--provider namecodexbar config set-api-key写入 API Key--provider、--stdin/--api-key、--no-enable、--label、--usage-scope、--organization-id、--workspace-idcodexbar config validate校验配置并报告问题--json、--prettycodexbar config dump输出归一化脱敏配置--pretty、--show-secretscodexbar cost --days N临时覆盖成本历史窗口--days1...365、--format json、--prettycodexbar usage --provider name单次抓取覆盖不写配置--provider、--json所有命令均支持统一的输出偏好参数--format text|json、--json、--json-only、--pretty、--verbose、--log-leveltrace|verbose|debug|info|warning|error|critical。常见工作流组合CI 门禁初始化隔离配置 → 启用所需 provider → 校验 → 抓取export CODEXBAR_CONFIG/tmp/ci-codexbar.json codexbar config enable --provider grok codexbar config validate codexbar usage --provider grok --json --pretty脚本化密钥分发为多个 provider 批量写入密钥export CODEXBAR_CONFIG$HOME/.config/codexbar/config.json printf %s $GROQ_API_KEY | codexbar config set-api-key --provider groq --stdin printf %s $DEEPGRAM_API_KEY | codexbar config set-api-key --provider deepgram --stdin codexbar config validate手改配置后的安全检查codexbar config validate || echo config has errors codexbar config dump --pretty # 确认脱敏后的实际生效结构源码实现地图命令路由与各子命令实现Sources/CodexBarCLI/CLIConfigCommand.swift命令注册config子命令的validate/dump/providers/enable/disable/set-api-key定义Sources/CodexBarCLI/CLIEntry.swift配置路径解析、原子写入与 0600 权限Sources/CodexBarCore/Config/CodexBarConfigStore.swift配置模型与归一化/脱敏逻辑Sources/CodexBarCore/Config/CodexBarConfig.swift配置校验规则Sources/CodexBarCore/Config/CodexBarConfigValidation.swiftprovider 凭据支持检查Sources/CodexBarCore/Config/ProviderConfigEnvironment.swift--days解析与钳制Sources/CodexBarCLI/CLICostCommand.swiftz.ai 团队/个人配置形态docs/zai.md结语codexbar config是 CodexBar 面向脚本化运维的完整入口它与 App 共享同一份解析配置、以0600权限安全落盘、支持CODEXBAR_CONFIG隔离环境并提供结构化的校验输出与脱敏检视能力。结合cost --days的临时窗口覆盖与usage --provider的单次覆盖你可以完全绕开图形界面把 provider 管理、密钥分发与成本报告无缝嵌入日常脚本与 CI 流水线。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考