OpenAI Codex 放出 Python SDK!一行 pip install,8 万 Star 的 AI 编程 Agent 直接嵌入你的应用

一行 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 上的包元数据：

• 包名：`openai-codex`
• 作者：OpenAI
• 当前版本：0.1.0b2
• Python 要求：>=3.10
• 开发状态：Beta
• 最新 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 功能一致吗？
  feature parity 问题没有官方回答。

这些问题目前都悬着。打算在项目里用这个 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 —