Open Interpreter 认证配置全解：ChatGPT 登录、API 密钥、本地模型与兼容 Provider 实战指南

Open Interpreter 认证配置全解：ChatGPT 登录、API 密钥、本地模型与兼容 Provider 实战指南

【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter

本篇技术指南基于 docs/authentication.md 展开，系统讲解 Open Interpreter 的四种认证路径：ChatGPT 账号登录、API 密钥、本地模型（Ollama / LM Studio）以及 OpenAI 兼容 Provider 的配置方法。读完本文，你将能够针对不同部署场景（交互终端、CI 流水线、无头服务器、纯本地推理）选择合适的认证方式，并深入理解凭据存储（keyring / 文件 / 内存）的底层实现与回退机制。

认证概览：Provider 无关设计

Open Interpreter 的认证体系是provider-agnostic（供应商无关）的：首次启动interpreter时会询问你希望如何认证，之后随时可以通过 TUI 中的/model命令切换认证方式与模型来源。

四类认证方式的适用场景：

认证方式	适用场景	凭据载体
ChatGPT 登录	个人交互式使用，享受账号订阅	可刷新的 OAuth 凭据（存入凭据存储）
API 密钥	CI、无头机器、显式按量计费	环境变量
本地 Provider	模型流量完全留在本机	无需密钥（本地服务）
OpenAI 兼容 Provider	自建网关、第三方推理服务	配置项 + 环境变量

ChatGPT 登录

启动 TUI 并选择 ChatGPT sign-in：

interpreter

这会打开一个浏览器登录流程，并将**可刷新的凭据（refreshable credentials）**保存到已配置的凭据存储中。整个过程包含 PKCE 等安全机制，相关实现位于 codex-rs/login 模块（见 pkce.rs、server.rs 以及登录回调页面 success_page.rs）。

源码视角：登录后到底存了什么

从源码结构看，认证状态的完整结构定义在 codex-rs/login/src/auth/storage.rs 的AuthDotJson中，包含以下字段：

pub struct AuthDotJson { pub auth_mode: Option<AuthMode>, #[serde(rename = "OPENAI_API_KEY")] pub openai_api_key: Option<String>, pub tokens: Option<TokenData>, // OAuth token 数据 pub last_refresh: Option<DateTime<Utc>>, // 上次刷新时间 pub agent_identity: Option<AgentIdentityStorage>, pub personal_access_token: Option<String>, pub bedrock_api_key: Option<BedrockApiKeyAuth>, }

这解释了"refreshable credentials"的含义：除 access token 外还持久化了tokens与last_refresh，客户端可在过期时主动换取新凭据；token 刷新流程有专门测试覆盖，见 auth_refresh.rs。

API 密钥

API 密钥最适合CI、无头机器和显式 Provider 计费的场景。以 OpenAI 为例：

export OPENAI_API_KEY=sk-... interpreter

其他 Provider 使用各自的环境变量，例如ANTHROPIC_API_KEY，或由其 Provider 条目配置的变量。

内置 Provider 目录

仓库中内置了一份 Provider 目录 provider_catalog.json，其中为每个内置 Provider 声明了env_key、base_url和wire_api。例如 Anthropic 条目：

{ "id": "anthropic", "name": "Anthropic", "env_key": "ANTHROPIC_API_KEY", "base_url": "https://api.anthropic.com", "wire_api": "messages" }

从这份目录可以看出两点实现事实：

• 只需导出ANTHROPIC_API_KEY环境变量即可使用 Anthropic，无需在配置中重复声明base_url；
• wire_api决定底层协议风格——OpenAI 兼容服务使用"responses"/"chat"，而 Anthropic 使用"messages"，这与下文兼容 Provider 配置中的wire_api字段一致。

此外，密钥并非只能来自环境变量：AuthDotJson还支持personal_access_token、bedrock_api_key等字段（见 storage.rs），说明不同认证形态最终会汇聚到同一份持久化结构中。

本地 Provider

如果你希望模型流量完全留在本机，可以使用本地 Runner：

Provider	说明
Ollama	启动 Ollama 后从/model中选择它，或直接使用--oss参数
LM Studio	启动本地服务器后，从/model中选择 LM Studio

interpreter --oss "summarize this repo with my local model"

--oss的底层行为

--oss不只是切换 Provider，它还会触发一次"本地环境准备"流程。以 Ollama 为例，codex-rs/ollama/src/lib.rs 中定义了：

/// 未显式指定 -m 时，--oss 使用的默认模型 pub const DEFAULT_OSS_MODEL: &str = "gpt-oss:20b"; /// 当选择 --oss 时准备本地 OSS 环境： /// - 确保本地 Ollama 服务器可达 /// - 检查模型是否存在，缺失则自动拉取 pub async fn ensure_oss_ready(config: &Config, client: &OllamaClient) -> std::io::Result<()> { ... }

也就是说，--oss的实际执行链是：连接本地 Ollama → 若本地没有gpt-oss:20b（或-m指定的模型）则自动pull→ 再进入会话。LM Studio 侧有对应的对称实现 codex-rs/lmstudio/src/lib.rs。

另一个值得注意的约束来自 ensure_responses_supported：使用 Responses 协议时要求Ollama 版本不低于 0.13.4，否则会报Ollama {version} is too old错误（0.0.0开发版本视为放行）。如果你的本地 Ollama 版本较旧且--oss失败，可优先升级 Ollama。相关测试（ollama/src/lib.rs）精确验证了0.13.3不通过、0.13.4及以上通过的边界行为。

兼容 Provider（OpenAI-Compatible）

对于任意 OpenAI 兼容的服务（自建网关、第三方推理平台），在配置文件中声明一个 Provider 条目即可：

model_provider = "acme" model = "acme-coder" [model_providers.acme] name = "Acme" base_url = "https://api.acme.example/v1" env_key = "ACME_API_KEY" wire_api = "responses"

然后设置对应密钥并启动：

export ACME_API_KEY=... interpreter

更多可用字段

对照 docs/config-reference.md 的 Provider 表说明，[model_providers.*]还支持重试与超时调优：

[model_providers.example] name = "Example" base_url = "https://api.example.com/v1" env_key = "EXAMPLE_API_KEY" wire_api = "responses" request_max_retries = 4 stream_max_retries = 5 stream_idle_timeout_ms = 300000

对于需要动态 token 的网关，认证还可以由命令提供，而非静态环境变量：

[model_providers.example.auth] command = "example-token" args = ["print"] refresh_interval_ms = 300000 timeout_ms = 5000

该命令按refresh_interval_ms周期刷新 token，适合企业内部 IAM 网关等短期凭据场景。

凭据存储（Credential Storage）

cli_auth_credentials_store = "auto" # "auto" | "keyring" | "file"

Open Interpreter 将用户状态保存在~/.openinterpreter/目录下；如果启用文件存储，请把auth.json当作密码一样对待。

源码级实现：四种存储后端与回退逻辑

存储模式的枚举定义在 codex-rs/config/src/types.rs：

/// Determine where Codex should store CLI auth credentials. pub enum AuthCredentialsStoreMode { /// Persist credentials in CODEX_HOME/auth.json. File, /// Persist credentials in the keyring. Fail if unavailable. Keyring, /// Use keyring when available; otherwise, fall back to a file in CODEX_HOME. Auto, /// Store credentials in memory only for the current process. Ephemeral, }

对应的后端实现在 codex-rs/login/src/auth/storage.rs 的create_auth_storage_with_store工厂函数（L507-L525）中按模式分派：

• File（FileAuthStorage）：将AuthDotJson序列化写入auth.json。注意其保存逻辑在 Unix 上会以0o600权限创建文件（仅属主可读写），这是"把 auth.json 当密码对待"的代码级落地：

  #[cfg(unix)] { options.mode(0o600); }

• Keyring：写入系统密钥环（keyring）。实现上将codex_home路径做 SHA-256 哈希取前 16 位十六进制作为稳定短键（compute_store_key），服务名为"Codex Auth"；写入 keyring 成功后还会主动删除磁盘上的auth.json残留，避免明文落盘。

• Auto（AutoAuthStorage）：加载时先查 keyring，查不到或失败则回退读auth.json；保存时 keyring 失败则回退写文件并记录 warn 日志。这正是文档推荐"auto"的原因——桌面环境用 keyring，无 keyring 的服务器环境自动降级为文件，无需人工干预。

• Ephemeral（EphemeralAuthStorage）：凭据仅存于进程内内存 map，进程结束即消失，适合一次性容器、评测沙箱等不希望任何凭据持久化的场景（文档注释中提到的三种取值之外，源码还支持这一模式）。

从源码结构看，keyring后端本身还有 Direct / Secrets 两种子形态（AuthKeyringBackendKind，见 types.rs）：Direct 直接把序列化后的凭据放进系统 keyring；Secrets 则把凭据写进本地加密 secrets 文件、仅把文件密钥放进 keyring，且 Windows 平台默认采用 Secrets 形态。

登出（Sign Out）

在 TUI 内执行：

/logout

或者在支持登出的登录入口中执行其 logout 命令。登出会同时清理 keyring 条目与auth.json文件——AuthStorageBackend::delete接口（storage.rs）要求后端同时处理两类残留，端到端行为由 logout.rs 测试保证。

实践建议小结

• 个人 TUI 使用：ChatGPT 登录 + 默认"auto"存储最省心；
• CI / 无头机器：API 密钥 + 环境变量，避免任何凭据落盘；如需更强隔离可评估ephemeral模式；
• 数据不出本机：Ollama / LM Studio +--oss，注意 Ollama 的 Responses API 版本下限 0.13.4；
• 自建/第三方 OpenAI 兼容网关：[model_providers.*]配置 + 按需开启命令式 token 刷新；
• 安全红线：文件存储模式下~/.openinterpreter/中的auth.json与 API 密钥同等敏感，备份与共享前务必加密或删除。

【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter