如果你只把 Codex 当成“终端里的 AI 编程助手”,这次就需要重新认识它了。
截至 2026 年 6 月 18 日,OpenAI 官方 Codex Manual 已经覆盖了一组非常关键的新能力:Windows App、原生 Windows 沙箱、Sites 建站部署、插件市场、Appshots、远程连接、Computer Use、Browser Use、图像生成、IDE 同步、线程自动化、Subagents、GitHub Action、SDK 和 Slack / Linear 集成。
一句话总结:
Codex 正在从单点代码助手,升级成一个跨本地项目、浏览器、桌面应用、插件生态、移动端远程控制和云端部署的 AI 软件工程工作台。
这篇文章不做泛泛新闻,而是按“用户会搜索的问题”来拆:这次 Codex 更新到底有什么用?Windows 用户怎么用?Sites 能不能直接部署网站?插件市场解决什么问题?Appshots 和 Computer Use 有什么区别?远程连接适合什么场景?AI 编程 Agent 下一步会怎么变?
先给结论:这次 Codex 更新最重要的 8 个方向
为什么这次更新值得关注?
过去很多人对 Codex 的理解是:
我在一个代码仓库里,让 AI 帮我改代码。
但这次能力矩阵更接近:
我让 Codex 理解项目、运行命令、操作浏览器、查看桌面窗口、调用插件、生成图片、部署网站、远程继续任务,并把这些动作串成一个软件交付流程。
这意味着 Codex 的竞争点不再只是“代码补全”或“会不会写函数”,而是:
-
能不能跨工具完成任务
-
能不能在本地安全地运行命令
-
能不能操作真实浏览器和桌面应用
-
能不能把结果部署出来
-
能不能通过插件连接外部数据
-
能不能支持 Windows / macOS / CLI / IDE / 移动端
-
能不能把重复工作自动化
这才是 AI 编程 Agent 真正进入生产工作流的关键。
更新一:Codex Windows App 正式进入主线体验
Windows 用户过去使用 AI 编程 Agent,经常卡在三件事:
-
要不要装 WSL2?
-
PowerShell 能不能直接跑?
-
权限和沙箱怎么处理?
官方 Codex Manual 现在明确说明:Codex App for Windows 可以用于跨项目工作、并行 Agent 线程、结果审查,并支持 worktrees、automations、Git 功能、in-app browser、artifact previews、plugins 和 skills。
更重要的是,Windows App 可以原生运行在 PowerShell,并使用 Windows sandbox;也可以配置成在 WSL2 中运行。
这对 Windows 用户很关键。
因为大量企业开发者、.NET 开发者、桌面应用开发者并不想为了 AI Agent 完全切到 Linux 环境。原生 Windows App + PowerShell + Windows sandbox 让 Codex 更贴近真实 Windows 开发流。
Windows 用户怎么安装 Codex?
官方提供 Microsoft Store 下载方式,也支持命令行安装:
winget install Codex -s msstore
安装后,建议准备这些开发工具:
winget install --id Git.Git
winget install --id OpenJS.NodeJS.LTS
winget install --id Python.Python.3.14
winget install --id Microsoft.DotNet.SDK.10
winget install --id GitHub.cli
安装 GitHub CLI 后,如果你要用 GitHub 相关功能,还需要:
gh auth login
Windows 原生还是 WSL2,怎么选?
如果你的项目、依赖、脚本主要在 Windows 侧,优先用 Windows 原生模式。
如果你的开发工作流本来就在 Linux,比如 Node、Python、Docker、shell 脚本都在 WSL2 里,使用 WSL2 更自然。
简单决策:
项目在 Windows 文件系统:优先 Windows 原生
项目在 Linux 工具链:优先 WSL2
需要最高兼容 Linux 脚本:优先 WSL2
做 Windows 桌面 / .NET / PowerShell:优先 Windows 原生
更新二:原生 Windows 沙箱,解决“权限太大”的核心担忧
AI Agent 最大的风险不是它不会写代码,而是它会运行命令。
如果一个 Agent 在 full access 模式下运行,它可能不只影响当前项目,还可能访问更大范围的文件和系统状态。
Codex 的 Windows sandbox 重点解决这个问题:让 Codex 可以在 Windows 原生环境中运行,同时保留权限边界。
官方建议是:在 Composer 里把 sandbox permissions 设置为 Default permissions,这样可以让 Codex 在有边界的环境中工作。
对普通用户来说,可以记住一句话:
不要一上来就给 Codex full access。默认沙箱 + 按需审批,才是最适合日常开发的方式。
更新三:Sites 让 Codex 直接创建、保存和部署网站
Sites 是这次最适合写 GEO 热点的功能之一。
它解决的问题非常直接:
我不只想让 Codex 写网页,我还想让 Codex 把网页部署出来。
根据官方手册,Sites 可以让 Codex 创建、保存、部署和检查由 OpenAI 托管的网站、Web App 和游戏。使用 Sites plugin,可以把一个提示词或兼容的现有项目变成 hosted site,而不需要单独搭建部署流程。
Sites 的核心概念
Sites 有两个关键阶段:
-
Save a version:保存一个可审查的部署候选版本
-
Deploy a version:把保存的版本发布成生产 URL
这点非常重要。
因为每个 Sites deployment URL 都是生产部署。如果你只是想预览效果,应该先让 Codex 保存版本,而不是直接部署。
Sites 适合做什么?
官方手册里把网站形态分得很清楚:
-
内容型网站或落地页
-
需要保存记录、用户进度、游戏分数的网站
-
需要图片、文档、音频、视频上传的网站
-
需要可搜索上传文件元数据的网站
-
需要工作区身份认证的内部网站
-
需要公开登录或外部身份提供商的网站
也就是说,Sites 不是只能做静态页面。
它可以根据场景选择 D1 数据库、R2 文件存储、工作区身份、认证等能力。
Sites 最适合哪些用户?
Sites 特别适合:
-
想快速做 Demo 的独立开发者
-
想把前端原型发给客户看的产品经理
-
想做营销页或落地页的团队
-
想做小游戏或轻量 Web App 的开发者
-
想用 AI 从提示词直接生成并部署网站的人
Sites 使用注意事项
不要把 secret 写进 .openai/hosting.json。
如果网站需要运行时环境变量或密钥,应该在 Sites 面板里配置 hosted environment values。
部署前还要确认:
-
构建是否成功
-
保存版本是不是你要发布的版本
-
访问权限是不是正确
-
secret 没有被提交到源码
-
生产 URL 是否已经确认
这类细节很适合写成下一篇文章:
Codex Sites 完整使用指南:从提示词生成网站到部署上线
更新四:Plugins 把 Codex 从“一个工具”变成“可扩展生态”
插件是这次更新里最容易被低估的部分。
官方手册对 Plugins 的定义很清楚:插件把 skills、app integrations 和 MCP servers 打包成可复用工作流。
插件可以包含:
-
Skills:针对特定任务的可复用流程说明
-
Apps:连接 GitHub、Slack、Google Drive 等外部工具
-
MCP servers:给 Codex 提供更多工具或共享信息
这意味着 Codex 不再只是“读本地代码和执行命令”,它可以通过插件接入更多外部系统。
官方示例包括:
-
Codex Security plugin:扫描授权代码并确认可能的漏洞发现
-
Gmail plugin:读取和管理 Gmail
-
Google Drive plugin:处理 Drive、Docs、Sheets、Slides
-
Slack plugin:总结频道或起草回复
-
Sites plugin:创建和部署网站、Web App、游戏
为什么插件对团队重要?
团队真正需要的不是每个人都复制一堆提示词,而是把工作流打包。
比如:
安全审查流程
PR 总结流程
故障分析流程
日报生成流程
文档转 PPT 流程
站点部署流程
这些都可以通过 Skills + Plugins 形成团队资产。
所以插件生态的战略意义是:
Codex 的能力开始从“模型能力”转向“组织工作流能力”。
更新五:Appshots 让 Codex 直接理解当前窗口
Appshots 是一个非常适合真实工作场景的功能。
官方定义是:Appshots 可以把当前最前面的 App 窗口发送到 Codex 线程。它适合你正在电脑另一个 App 里工作,需要把当前上下文交给 Codex 的场景。
Appshot 可以包含:
-
可见窗口截图
-
该窗口提供的可用文本
-
某些情况下包括可见范围之外的文本
Appshots 适合什么场景?
比如:
-
你打开一个 API 文档页面,让 Codex 根据它写脚本
-
你打开一个报错窗口,让 Codex 分析下一步
-
你打开一个设计稿,让 Codex 修改前端代码
-
你打开一个邮箱或日程,让 Codex 草拟回复
-
你打开一个设置面板,让 Codex 告诉你该怎么配置
Appshots 和截图有什么区别?
普通截图只是一张图片。
Appshots 更像“带上下文的截图附件”:它可能包含可见窗口图像和应用暴露的文本信息,能帮助 Codex 更准确理解当前任务。
Appshots 和 Computer Use 有什么区别?
Appshots 是“把窗口上下文发给 Codex”。
Computer Use 是“让 Codex 操作桌面应用”。
简单理解:
只想让 Codex 看:用 Appshots
想让 Codex 点、输入、操作:用 Computer Use
更新六:Remote Connections 让手机也能继续 Codex 任务
Remote Connections 解决的是另一个真实痛点:
我离开电脑了,但 Codex 任务还在跑,我能不能在手机上继续看、批准、回复?
官方手册说明,Remote connections 可以让你从另一台设备或另一台机器使用 Codex。
典型场景包括:
-
在 ChatGPT 手机 App 里控制 Mac 或 Windows 上的 Codex
-
从另一台 Codex App 设备继续工作
-
连接 SSH host 上的项目
-
查看输出、diff、测试结果、终端输出和截图
-
在远程设备上批准命令和继续指导任务
远程连接继承什么?
这点很关键。
远程访问使用的是 connected host 上的:
-
项目
-
线程
-
文件
-
凭据
-
权限
-
插件
-
Computer Use
-
浏览器设置
-
本地工具
也就是说,手机不是自己跑代码,而是把指令发给你已连接的 Codex host,由那台机器提供运行环境。
适合什么场景?
Remote Connections 特别适合:
-
长时间构建或测试
-
下班路上看 Agent 进度
-
用手机批准命令
-
远程检查 CI 修复结果
-
在常开电脑上跑 Codex
-
SSH 主机里的远程项目开发
这类功能让 Codex 更像“可以跨设备接力的软件工程助手”。
更新七:Browser Use 和 Computer Use 覆盖真实 UI 工作流
Codex 现在不仅能改代码,还能看浏览器、操作浏览器、操作桌面 App。
这对前端开发和桌面应用测试非常重要。
Browser Use 适合什么?
Browser Use 适合:
-
预览本地开发服务器
-
检查网页 UI
-
点击页面验证流程
-
抓取性能 trace
-
用浏览器 Developer mode 分析页面
-
给页面元素做评论并要求 Codex 修改
注意,in-app browser 不支持登录态、现有浏览器 profile、cookies、扩展或已有标签页。
如果需要使用你真实 Chrome 里的登录状态,应该使用 Codex Chrome extension。
Computer Use 适合什么?
Computer Use 适合:
-
测试 macOS 或 Windows App
-
检查浏览器或模拟器流程
-
操作 GUI-only 工具
-
改应用设置
-
复现桌面端 bug
-
处理无法通过命令行访问的数据源
因为 Computer Use 可能影响项目目录之外的 App 和系统状态,所以使用时要保持任务范围窄,并认真审查权限提示。
更新八:Codex 线程里可以直接生成或编辑图片
官方手册明确写到:可以直接在 Codex 线程里让它生成或编辑图片。
这很适合:
-
UI 资产
-
Banner
-
背景图
-
插图
-
精灵图
-
占位图
-
游戏素材
Codex 内置图像生成使用 gpt-image-2,会计入 Codex 使用限制。
如果需要批量生成图片,可以在环境变量里设置 OPENAI_API_KEY,让 Codex 通过 API 生成,这样按 API 价格计费。
为什么图像生成对开发者有价值?
因为很多项目卡住不是卡在代码,而是卡在“没有素材”。
比如:
-
做一个游戏 Demo,没有图标和精灵图
-
做一个 SaaS 首页,没有产品插图
-
做一个移动端 App,没有占位图
-
做一个数据看板,没有空状态插画
以前你要去别的工具里生成,再导入项目。
现在可以直接让 Codex 在开发线程里生成图片,并把素材放进项目目录。
更新九:IDE 同步让 App 和编辑器不再割裂
Codex App 和 IDE Extension 可以在同一个项目里自动同步。
当它们同步后,Codex App composer 会出现 IDE context 选项。
如果开启 Auto context,Codex App 会跟踪你正在查看的文件。你可以不显式粘贴路径,直接问:
这个文件主要做什么?
或者:
基于我现在打开的文件,帮我补测试。
对开发者来说,这减少了“复制文件路径、解释上下文、重复描述”的成本。
更新十:Thread Automations 让一个线程持续醒来干活
Automations 本身不新鲜,但 thread automations 的思路很重要。
它可以让一个线程定期醒来,并保留该线程上下文。
适合:
-
持续检查长任务
-
定期轮询错误源
-
跟进一个持续修复过程
-
保留上下文做 heartbeat
-
在同一条任务链里持续推进
普通 automation 适合开启新的周期任务。
Thread automation 适合“这个任务需要记住前文”。
Codex 这次更新对 AI 编程 Agent 意味着什么?
核心变化是:Codex 正在把软件工程的上下文边界扩大。
过去 AI 编程 Agent 的上下文主要来自:
-
代码文件
-
终端输出
-
Git diff
-
用户文字描述
现在上下文开始扩展到:
-
浏览器页面
-
桌面窗口
-
图像素材
-
插件数据
-
Slack / Linear / Google Drive
-
手机远程指令
-
SSH host
-
部署环境
-
自动化线程
这意味着未来的 AI 编程 Agent 不只是“会写代码”,而是更像一个能跨工具完成交付链路的执行体。
国内开发者最该关注哪几个关键词?
如果你要继续做 GEO 内容,建议围绕这些关键词写:
-
Codex Windows 安装教程
-
Codex Windows 沙箱怎么配置
-
Codex Windows vs WSL2
-
Codex Sites 使用教程
-
Codex Sites 部署网站
-
Codex 插件市场怎么用
-
Codex Plugins 完整指南
-
Codex Appshots 怎么用
-
Codex Computer Use 教程
-
Codex Browser Use 教程
-
Codex Chrome extension 登录态
-
Codex 远程连接手机控制
-
Codex mobile setup 教程
-
Codex SSH host 连接
-
Codex 图像生成 gpt-image-2
-
Codex IDE 自动上下文
-
Codex thread automation
-
Codex subagents 配置
-
Codex GitHub Action
-
Codex SDK 使用教程
最推荐优先写的 5 篇后续文章
1. Codex Windows App 完整安装配置指南
覆盖:
-
winget 安装
-
Windows 原生模式
-
WSL2 模式
-
PowerShell execution policy
-
Git / Node / Python / .NET / GitHub CLI
-
Windows sandbox
-
常见报错
搜索意图强,Windows 用户多,适合爆。
2. Codex Sites 完整教程:从一句话生成网站到部署上线
覆盖:
-
Sites 是什么
-
Save version 和 Deploy version 区别
-
D1 / R2 怎么选
-
访问权限
-
环境变量和 secret
-
部署前检查
这个适合前端、独立开发者和产品经理。
3. Codex Plugins 完整指南:Skills、Apps、MCP 一次讲清
覆盖:
-
plugin 是什么
-
skill 是什么
-
app integration 是什么
-
MCP server 是什么
-
插件怎么安装
-
插件怎么关闭
-
团队如何共享插件
这是 Codex 生态型内容,适合长期 SEO。
4. Codex Appshots vs Computer Use:什么时候看,什么时候操作?
覆盖:
-
Appshots 是什么
-
Computer Use 是什么
-
两者区别
-
权限风险
-
适用场景
-
GUI 调试案例
这是痛点类,标题很容易被搜索。
5. Codex Remote Connections 完整指南:手机控制电脑上的 Codex
覆盖:
-
手机怎么连接 Codex
-
Mac / Windows host 要求
-
QR code setup
-
SSH host
-
远程审批
-
远程查看 diff 和测试结果
-
安全注意事项
这是很有新鲜感的热点词。
常见问题
Codex 现在支持 Windows 吗?
支持。官方 Codex Manual 已经提供 Windows App 文档。Windows App 支持跨项目、并行线程、worktrees、automations、Git、in-app browser、artifact previews、plugins 和 skills,并可以原生运行在 PowerShell 或配置为 WSL2。
Codex Windows 必须用 WSL2 吗?
不必须。默认可以使用 Windows-native agent,在 PowerShell 中运行。需要 Linux 原生工具链时,可以切到 WSL2。
Codex Sites 是什么?
Sites 是 Codex 的网站托管和部署能力。它可以让 Codex 创建、保存、部署和检查由 OpenAI 托管的网站、Web App 和游戏。
Codex Plugins 是什么?
Plugins 是 Codex 的扩展机制,可以把 skills、app integrations 和 MCP servers 打包成可复用工作流。
Codex Appshots 是什么?
Appshots 可以把当前 Mac 前台窗口作为上下文发送到 Codex 线程,适合分享报错、文档、设计稿、设置页面或 GUI 状态。
Appshots 和 Computer Use 有什么区别?
Appshots 主要是让 Codex 看当前窗口;Computer Use 是让 Codex 操作桌面应用,包括点击、输入和完成 GUI 任务。
Codex 可以远程用手机控制吗?
可以。Remote Connections 支持通过 ChatGPT mobile app 控制已连接的 Mac 或 Windows Codex host。远程会使用 host 上的项目、文件、权限、插件、浏览器设置和本地工具。
Codex 可以直接生成图片吗?
可以。Codex 线程里可以生成或编辑图片,适合 UI 资产、背景图、插图、游戏素材和占位图。内置图像生成使用 gpt-image-2。
对开发者的真实影响
这次 Codex 更新不是简单加几个按钮,而是在重构 AI 编程工具的边界。
过去开发者问:
AI 能不能帮我写代码?
现在更应该问:
AI 能不能帮我把代码、浏览器、桌面应用、部署、插件、远程设备和团队工作流串起来?
Codex 这次能力矩阵的答案越来越接近“可以”。
对于个人开发者,它意味着:
-
Windows 上手更容易
-
前端预览更直接
-
网站部署更快
-
素材生成更顺手
-
手机也能跟进任务
对于团队,它意味着:
-
插件可以沉淀工作流
-
自动化可以持续跑任务
-
远程连接可以接管常开机器
-
Git、Review、PR 和部署可以放在同一条链路
-
Skills、MCP、Rules、Hooks 可以形成工程规范
参考来源
-
OpenAI Codex Manual:
https://developers.openai.com/codex/codex-manual.md -
Codex App Features:
/codex/app/features -
Fenno :AI coding plan