Codex 這次的更新，比「多一個部署按鈕」還要實際一點。X 上的 Codex Changelog 把重點濃縮成三件事：Sites plugin、側邊欄專案管理、環境變數與 secrets。真正會改變使用方式的，是你可以在 Codex App 裡把一個網站、dashboard、內部工具或小遊戲，從 prompt 走到可保存版本，再走到 OpenAI hosting。
原始貼文發布在 2026 年 6 月 3 日凌晨，連到 OpenAI Developers 的 Codex changelog。官方文件裡，Sites 被描述成讓 Codex 建立、保存、部署、檢查 hosted sites 的 plugin，支援 websites、web apps、dashboards 和 games。這不是把 Vercel 或 Cloudflare 的流程換一個名字，而是把「做出來」和「放到哪裡、誰能看、環境值放哪裡」放回同一個工作脈絡。
Sites 先解決的是部署斷點
以前請 Codex 做一個前端工具，最常卡住的不是第一版 UI，而是後面那段：build 要不要改、部署格式合不合、要不要另開一套 hosting、誰來看、環境變數放哪裡。Sites 把這些步驟變成 Codex App 裡的同一條線。
官方文件有一個很值得畫線的提醒：Sites 的 deployment URL 是 production deployment。如果只是要先看成果，不應該急著 deploy，而是要求 Codex save a version。這句話很像小字提醒，但其實是 Sites 工作流的核心。先保存可部署版本，確認 build、內容和存取權限，再決定要不要發布。
專案面板讓它不像一次性 demo
X 貼文提到 sidebar project manager with env vars and secrets。對內部工具來說，這比「可以部署」本身更重要。只要網站會讀 API key、Webhook URL、資料庫 binding，或需要限制誰能進來，部署工具就不能只管 build 成功。
OpenAI 的 Sites 文件也把幾個控制點講得很清楚：ChatGPT Business workspace 預設可用；Enterprise 需要 admin 透過 RBAC 開啟；hosted environment variables 和 secrets 要放在 Sites panel，不要寫進 source 或 .openai/hosting.json；更改 hosted values 後，要 redeploy 已核准的 saved version，下一次部署才會套用。
適合什麼，不適合什麼
- 適合：內部 dashboard、臨時營運工具、資料查詢介面、活動頁、小型互動 demo，需要快速從 Codex 產出到可分享網址。
- 也適合：需要 workspace identity、D1 這類結構化資料、R2 這類上傳檔案儲存的 Sites 專案，但要在 prompt 裡先講清楚資料需求。
- 先不要急：面向公開使用者、涉及付款、個資、長期維運或法務審查的產品，不要因為 Sites 能 deploy 就直接公開。先 save version，看 source diff、build、access mode、secrets，再分享。
這次更新讓 Codex App 更像一個小型產品工作台。它不是只幫你寫程式，也開始接住「做完之後放哪裡」那段原本散在外面的流程。這會讓很多原型和內部工具更快落地，也會讓「先 review，後 deploy」變得更重要。