OpenAI Codex 上线「Sites」插件:prompt 写完,应用直接部署到生产环境!自带托管、权限和 secrets 管理

Codex 的边界又往前推了

6 月 2 日，Codex Changelog 账号发了一条产品更新：

"🚀 Codex app update
🌐 Sites plugin: deploy apps, dashboards, and games on OpenAI hosting
🗂 Sidebar project manager with env vars and secrets
🔐 Business default; Enterprise via RBAC"

「Codex app 更新——Sites 插件：把应用、dashboard 和游戏部署到 OpenAI 托管；侧边栏项目管理器支持环境变量和 secrets；Business 默认开启，Enterprise 通过 RBAC 控制。」

▲ Codex Changelog 官方推文，宣布 Sites 插件上线

看上去只是一次常规产品迭代？仔细看就会发现，这次更新的含义远超表面。

Codex 过去的定位很明确：读代码、改代码、跑代码、提 PR。但 Sites 把边界往前推了一大步——写完代码之后的 build、deploy、权限配置、secrets 管理，全部收进了同一个对话窗口。

过去，开发者让 AI 写完前端，还得手动去接 Vercel、Netlify、Cloudflare Workers，自己配环境变量、设访问控制、生成分享链接。现在，Codex 要把这些环节全部吃下来。

▲ OpenAI 官方 changelog：Sites 在 Codex app 中进入 preview

从 prompt 到上线，四步走完

OpenAI 的 Sites 文档把整个流程拆得很干脆，四步：

第一步：在 Codex thread 里描述你想要的站点，可以显式写 `@Sites`，告诉 Codex 最终目标是托管部署。

第二步：让 Codex 验证 build，然后选择「保存可审查版本」或「部署已批准版本」。

第三步：部署成功后，Codex 返回 production URL。

第四步：在 app 侧边栏打开 Sites，管理项目、版本和部署状态。

▲ Sites 文档：从 prompt 到托管站点的完整工作流

但这里有一个关键细节：每个 Sites deployment URL 都是生产环境部署。

官方文档原话：

"Every Sites deployment URL is a production deployment."

「每个 Sites 部署 URL 都是生产环境部署。」

所以，如果只想在上线前审查效果，应该让 Codex 保存版本但不部署。点了 deploy，链接就直接指向生产环境——没有"预览"这回事。

这个设计决策说明 OpenAI 对 Sites 的定位很认真：它面向的是真实业务场景，而非玩具级 demo。

企业级权限控制：Business 默认开，Enterprise 靠 RBAC

Sites 的权限体系明显对准了企业内部场景。

ChatGPT Business工作区默认包含 Sites，开箱即用。ChatGPT Enterprise则需要管理员在 admin settings 的 RBAC controls 中手动开启——企业安全策略优先。

部署之后，访问控制分三档：

• Owner and admins
  （`admins_only`）：只有站点 owner 和 workspace 管理员能访问
• Workspace
  （`workspace_all`）：workspace 内所有活跃用户
• Custom
  （`custom`）：指定特定用户或 workspace groups

内部工具、运营 dashboard、团队协作面板——这些场景天然适合。你可以用 Codex 生成一个数据看板，限定只有运营部门能访问，整个过程都在对话里搞定。不用单独开一个项目，不用找运维配权限。

▲ Sites 内置权限控制、环境变量与 secrets 管理

Secrets 和环境变量：AI 写应用最常断的那一环，补上了

过去用 AI 写一个需要 API key 或数据库连接的应用，流程往往在上线这一步卡住——代码写好了，但环境变量没配、secrets 没管、部署平台没接。中间要切好几个工具，链路一断就很难再接上。

Sites 把这个断点补上了。用户在 Codex app 侧边栏打开 Sites，选择项目，直接在 Sites panel 里添加、更新或删除环境变量和 secrets。

官方文档强调了几条红线：

• 不要
  把 secrets 放进 `.openai/hosting.json`
• 不要
  在 `.env` 文件里提交 secret values
• 更新环境变量后，需要让 Codex 重新部署已批准版本，新配置才会生效

逻辑很简单：secrets 走产品内管理通道，源码保持干净。这跟业界 best practice 完全一致，只是现在不用自己去配了，Codex 帮你管。

不只是静态页面——D1 数据库、R2 存储、用户认证都支持

Sites 的野心远超静态网页托管。文档列出了几类典型场景和对应方案：

• 内容型网站或 landing page
  ：默认无需持久状态
• 保存记录、用户进度或游戏分数
  ：用 D1 关系型数据库
• 图片、文档、音视频上传
  ：用 R2 对象存储
• 需要可搜索 metadata
  ：D1 存元数据，R2 存文件
• 内部站点需要当前 workspace 用户身份
  ：workspace-authenticated identity
• 公共登录或外部身份提供方
  ：authentication-enabled Sites project

技术底层上，Sites 托管的项目需要构建出Cloudflare Worker 兼容的 ES modules 输出。新项目可以用 Sites 提供的推荐 starter；已有项目建议先让 Codex 确认 build 兼容性，再请求部署。

前端渲染、后端数据、用户认证、文件存储——全链路打通。这已经具备了一个轻量应用平台的雏形。

竞争焦点正在转移

过去一年，AI coding agent 的竞争焦点集中在「谁更会写代码」——补全更准、上下文更长、多文件编辑更稳。

但 Sites 释放了一个明确的信号：下一阶段的竞争，可能要看谁能把应用安全地交付给真实用户。

写代码只是第一步。Build、deploy、权限、secrets、版本管理、访问控制——这些环节过去需要开发者手动对接各种平台，现在被 Codex 收进了对话窗口。从「帮你写代码」到「帮你把应用交到用户手上」，Codex 往前迈了一大步。

目前 Sites 处于 preview 阶段，面向 ChatGPT Business 和 Enterprise 用户。OpenAI 表示更多 plan 将在后续开放。

对开发者来说，值得关注的核心变化在于：AI coding agent 的能力边界，正在从「帮你写」扩展到「帮你上线」。代码只是中间产物，交付才是终点。

— END —