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-ininterpreter这会打开一个浏览器登录流程并将**可刷新的凭据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: OptionAuthMode, #[serde(rename OPENAI_API_KEY)] pub openai_api_key: OptionString, pub tokens: OptionTokenData, // OAuth token 数据 pub last_refresh: OptionDateTimeUtc, // 上次刷新时间 pub agent_identity: OptionAgentIdentityStorage, pub personal_access_token: OptionString, pub bedrock_api_key: OptionBedrockApiKeyAuth, }这解释了refreshable credentials的含义除 access token 外还持久化了tokens与last_refresh客户端可在过期时主动换取新凭据token 刷新流程有专门测试覆盖见 auth_refresh.rs。API 密钥API 密钥最适合CI、无头机器和显式 Provider 计费的场景。以 OpenAI 为例export OPENAI_API_KEYsk-... 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_urlwire_api决定底层协议风格——OpenAI 兼容服务使用responses/chat而 Anthropic 使用messages这与下文兼容 Provider 配置中的wire_api字段一致。此外密钥并非只能来自环境变量AuthDotJson还支持personal_access_token、bedrock_api_key等字段见 storage.rs说明不同认证形态最终会汇聚到同一份持久化结构中。本地 Provider如果你希望模型流量完全留在本机可以使用本地 RunnerProvider说明Ollama启动 Ollama 后从/model中选择它或直接使用--oss参数LM Studio启动本地服务器后从/model中选择 LM Studiointerpreter --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及以上通过的边界行为。兼容 ProviderOpenAI-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 Storagecli_auth_credentials_store auto # auto | keyring | fileOpen 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中按模式分派FileFileAuthStorage将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残留避免明文落盘。AutoAutoAuthStorage加载时先查 keyring查不到或失败则回退读auth.json保存时 keyring 失败则回退写文件并记录 warn 日志。这正是文档推荐auto的原因——桌面环境用 keyring无 keyring 的服务器环境自动降级为文件无需人工干预。EphemeralEphemeralAuthStorage凭据仅存于进程内内存 map进程结束即消失适合一次性容器、评测沙箱等不希望任何凭据持久化的场景文档注释中提到的三种取值之外源码还支持这一模式。从源码结构看keyring后端本身还有 Direct / Secrets 两种子形态AuthKeyringBackendKind见 types.rsDirect 直接把序列化后的凭据放进系统 keyringSecrets 则把凭据写进本地加密 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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-ininterpreter这会打开一个浏览器登录流程并将**可刷新的凭据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: OptionAuthMode, #[serde(rename OPENAI_API_KEY)] pub openai_api_key: OptionString, pub tokens: OptionTokenData, // OAuth token 数据 pub last_refresh: OptionDateTimeUtc, // 上次刷新时间 pub agent_identity: OptionAgentIdentityStorage, pub personal_access_token: OptionString, pub bedrock_api_key: OptionBedrockApiKeyAuth, }这解释了refreshable credentials的含义除 access token 外还持久化了tokens与last_refresh客户端可在过期时主动换取新凭据token 刷新流程有专门测试覆盖见 auth_refresh.rs。API 密钥API 密钥最适合CI、无头机器和显式 Provider 计费的场景。以 OpenAI 为例export OPENAI_API_KEYsk-... 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_urlwire_api决定底层协议风格——OpenAI 兼容服务使用responses/chat而 Anthropic 使用messages这与下文兼容 Provider 配置中的wire_api字段一致。此外密钥并非只能来自环境变量AuthDotJson还支持personal_access_token、bedrock_api_key等字段见 storage.rs说明不同认证形态最终会汇聚到同一份持久化结构中。本地 Provider如果你希望模型流量完全留在本机可以使用本地 RunnerProvider说明Ollama启动 Ollama 后从/model中选择它或直接使用--oss参数LM Studio启动本地服务器后从/model中选择 LM Studiointerpreter --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及以上通过的边界行为。兼容 ProviderOpenAI-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 Storagecli_auth_credentials_store auto # auto | keyring | fileOpen 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中按模式分派FileFileAuthStorage将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残留避免明文落盘。AutoAutoAuthStorage加载时先查 keyring查不到或失败则回退读auth.json保存时 keyring 失败则回退写文件并记录 warn 日志。这正是文档推荐auto的原因——桌面环境用 keyring无 keyring 的服务器环境自动降级为文件无需人工干预。EphemeralEphemeralAuthStorage凭据仅存于进程内内存 map进程结束即消失适合一次性容器、评测沙箱等不希望任何凭据持久化的场景文档注释中提到的三种取值之外源码还支持这一模式。从源码结构看keyring后端本身还有 Direct / Secrets 两种子形态AuthKeyringBackendKind见 types.rsDirect 直接把序列化后的凭据放进系统 keyringSecrets 则把凭据写进本地加密 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考