导读【导读】OpenAI 团队成员刚刚宣布 Codex Python SDK 发布。开发者只需 `pip install openai-codex`，就能把 Codex 这个 AI 编程 Agent 直接嵌入 Python 应用和工作流。CLI、IDE 插件、Web 三大入口之外，Codex 终于有了编程控制面——当前版本 0.1.0b2，Beta 阶段，GitHub 仓库已有 87.9k Star。一行 pip install，Codex 多了第四个入口
6 月 2 日，OpenAI 团队成员 Vaibhav (VB) Srivastav 在 X 上宣布：
"We just released the Codex Python SDK 🔥 You can now embed Codex directly into your Python apps and workflows!"
「我们刚发布了 Codex Python SDK，你现在可以把 Codex 直接嵌入 Python 应用和工作流了！」
▲ Vaibhav (VB) Srivastav 在 X 上宣布 Codex Python SDK 发布
帖子列出的功能清单：启动 threads、运行 turns、流式查看进度、恢复 sessions、传入 images、控制 sandbox access，全部复用已有 Codex 认证。
安装命令一行：
```bash pip install openai-codex ```
看起来只是多了一个包。但 Codex 过去的使用入口只有三个——CLI 终端、IDE 插件、Web 界面——每一个都需要人坐在屏幕前操作。
现在第四个入口出现了：Python 代码。
你的 CI/CD pipeline、内部工具后台、定时脚本、监控告警系统，都可以在代码里直接调起 Codex，让它去读代码、定位 bug、提修复方案。不需要人盯着终端。
官方定义：编程控制本地 Codex Agent
OpenAI Developers 官方文档给 Codex SDK 的定位：
"Programmatically control local Codex agents"
「以编程方式控制本地 Codex Agent。」
▲ OpenAI Developers 官方 Codex SDK 文档页面
文档列出四个使用场景：
1.把 Codex 接入 CI/CD pipeline2.创建你自己的 Agent，与 Codex 协作完成复杂工程任务3.把 Codex 构建进内部工具和 workflows4.把 Codex 集成进你自己的应用
四条指向同一个方向：Codex 从"你打开一个工具来用"，变成了"你的系统里的一个可调用模块"。
过去 Codex 是个人生产力工具。现在它可以成为团队基础设施的一部分。
技术内核：本地 app-server + JSON-RPC
底层架构值得拆开看。
官方文档写明：Python SDK 控制本地 Codex app-server，通过 JSON-RPC 通信。发布构建包含 pinned Codex CLI runtime dependency，要求 Python 3.10+。
翻译成大白话：SDK 启动一个本地 Codex 服务进程，然后通过标准化协议跟它对话。跟调用云端 REST API 完全两码事——你的 Codex Agent 跑在本地，代码跟它之间走的是进程间通信。
来看官方示例：
```python from openai_codex import Codex, Sandbox
with Codex() as codex: thread = codex.thread_start( model="gpt-5.4", sandbox=Sandbox.workspace_write, ) result = thread.run( "Find the failing tests, explain the root cause, " "and propose a fix." ) print(result.final_response) ```
几行代码做了三件事：`Codex()` 启动本地 app-server；`thread_start` 创建编程会话，指定模型和 sandbox 权限；`thread.run()` 发出任务指令，拿回包含 final response、collected items 和 token usage 的结构化结果。
有开发者在帖子下面问：每次执行都 spawn 新的 node process 吗？
作者回复：不会。`Codex()` 启动的是一个本地 app-server process，SDK 通过 stdio/JSON-RPC 与它通信。整个设计围绕一个持久服务进程做会话和任务编排，每次调用不需要重新拉起进程。
文档还展示了 `AsyncCodex`——如果你的 Python 应用本身是异步架构，可以直接用 async 方式控制 Codex。
Resume 能恢复什么？官方给了明确边界
帖子提到的Resume sessions功能引来了追问：resume 恢复的是完整运行时状态，还是只有对话历史？
作者回复：
"resume restores the persisted thread, including conversation/run history and saved thread settings/config; does not resurrect live tool/process state."
「resume 恢复的是持久化 thread，包括对话/运行历史和保存的 thread 设置/配置；不会复活 live tool/process state。」
具体来说：如果 Codex 在之前的 session 里改了文件，文件系统改动还在；但打开的 shell 进程、临时句柄等活跃状态不会被恢复。
恢复范围限于持久化会话语义和配置，操作系统级进程快照不在其中。
对想用 SDK 做长时间任务编排的开发者来说，resume 可以接着上次的对话上下文继续工作，但不能假设上一轮跑到一半的命令行工具还活着。
当前状态：Beta 0.1.0b2，别急着上生产
PyPI 上的包元数据：
- 最新 wheel 上传时间：2026 年 5 月 28 日
▲ PyPI openai-codex 包：版本 0.1.0b2，Beta 状态
版本号和 Beta classifier 都指向同一个事实：SDK 还在早期阶段。接口可能变，行为可能调整，上生产需要自己评估风险。
但换个角度看，OpenAI 选择了尽早放出来让开发者试，没有等到 1.0。
同一个官方文档页面还列出了TypeScript SDK，安装命令 `npm install @openai/codex-sdk`，要求 Node.js 18+，强调 server-side 使用。SDK 路线同时覆盖了 Python 和 Node.js 两大主流服务端语言。
社区追问已经开始了
X 帖下面的回复暴露了开发者最关心的几个方向：
- 和 OpenAI Agents SDK 什么关系？
- 能用 OpenAI / Azure OpenAI API key 吗？帖子只说复用 existing Codex auth，key 和 Azure 集成细节没有展开。
- TypeScript SDK 和 Python SDK 功能一致吗？
这些问题目前都悬着。打算在项目里用这个 SDK 的开发者，建议自己验证边界。
Codex 正在换一种方式存在
▲ GitHub openai/codex：87.9k Stars，Apache-2.0 协议，主语言 Rust
GitHub 上 openai/codex 仓库的描述至今写着："Lightweight coding agent that runs in your terminal"。87.9k Stars，12.9k Forks，479 位贡献者，806 个 release。
但 Python SDK 的出现正在拓宽 Codex 的触达范围。
过去，用 Codex 要打开 CLI / IDE / Web，跟 Agent 对话，看它干活。现在，开发者可以让自己的 Python 服务、任务队列、CI runner、内部 dashboard 创建 thread，发起 turn，读取 streaming progress，接收结构化结果，并通过 sandbox 策略约束 workspace access。
从"人操作工具"到"系统调用组件"——这才是 Codex 这次 SDK 发布的真正意义。
Beta 就是 Beta，接口会变，边界在摸索，社区追问还没有完整回答。但方向已经亮出来了：Codex 的目标，从终端工具走向开发者基础设施。
— END —
10个月宝宝每天需要喝多少奶粉？
