01

先说结论:Setup scripts 负责初始化,Actions 负责重复操作

Codex 桌面应用的本地环境可以为 Worktree 定义自动初始化步骤,并把启动服务、构建、测试等常用命令做成顶部 Actions。Setup scripts 在创建新 Worktree 聊天时自动运行,Actions 则由用户需要时触发。

两者都应保持可重复、可观察且不包含硬编码密钥。配置会存放在项目根目录的 .codex 文件夹,可以纳入 Git 与团队共享,但环境变量和本机凭证应通过安全机制提供。

Codex Local environment Setup scripts Actions Worktree 初始化图
Codex Local environment Setup scripts Actions Worktree 初始化图
02

一、这个功能适用于哪里

官方当前说明,本地环境仅适用于 ChatGPT 桌面应用中的 Codex。需要先选择 Codex,再在应用设置中配置。CLI、普通 ChatGPT 网页或云环境不应直接照搬同一入口。

如果仓库包含多个项目,应打开包含共享 .codex 文件夹的项目目录。选错子目录会让设置、AGENTS.md 和 Git 根发现不符合预期,Actions 也可能在错误 cwd 执行。

03

二、为什么 Worktree 经常缺依赖

Worktree 是新的 Git 工作目录,跟踪文件会存在,但 node_modules、虚拟环境、构建缓存和多数被忽略的本地文件不会自然出现在新目录。直接运行测试时就可能提示模块、命令或配置缺失。

Setup script 的职责是从干净 checkout 重建可运行环境,例如安装锁定依赖、生成代码或完成初始构建。脚本不应依赖原本 Local 目录中的隐式状态。

04

三、怎样设计 Setup script

先列出新克隆仓库真正需要的步骤:验证运行时版本、安装依赖、执行代码生成、准备非敏感默认配置、运行快速构建检查。Node 项目可使用锁文件对应的安装命令,再执行必要 build。

脚本要支持重复运行,不应每次追加同一配置或覆盖开发者数据。发生错误时返回非零退出码并输出可理解信息,让用户知道缺的是网络、运行时、凭证还是项目文件。

05

四、平台差异怎样处理

官方允许为 macOS、Windows 或 Linux 定义平台专用 Setup scripts,用来覆盖默认脚本。只有路径、shell 或工具确实不同才拆分,公共步骤尽量保持一致,减少三套脚本长期漂移。

Windows 要明确 PowerShell 与其他 shell 的语法差异,Linux 与 macOS 要避免依赖未安装的系统包。团队应在各目标平台实际创建 Worktree 验证,而不是只检查配置文件格式。

06

五、Actions 适合放哪些命令

Actions 适合重复且明确的任务,例如启动开发服务器、运行单元测试、执行 lint、构建预览或打开本地检查。它们会显示在桌面应用顶部,并在集成终端中运行。

一次性排查仍可直接使用集成终端。不要把生产部署、密钥轮换或破坏性数据库迁移做成无确认的一键 Action;高影响操作应保留环境检查、审批与回滚。

07

六、Action 的工作目录和端口管理

Action 在当前项目或 Worktree 上下文中运行,脚本应使用相对项目根的稳定路径,并在启动前确认端口、进程与环境变量。不要默认本地 checkout 与 Worktree 共用同一端口。

并行聊天可能同时启动多个服务,建议允许通过环境变量分配端口,或在启动时检测占用并给出提示。停止 Action 后还要确认子进程是否退出,避免后台服务持续占用资源。

08

七、配置怎样分享给团队

本地环境配置存放在项目根 .codex 中,可提交到仓库,让团队成员获得一致的初始化与 Actions。提交前要检查文件中是否意外包含绝对用户路径、账号、Token 或本机特有信息。

共享配置应以锁文件和项目文档为事实来源。变更依赖或构建流程时同步更新 Setup script,并在 Pull Request 中说明影响。过期脚本比没有脚本更容易造成误判。

09

八、秘密与被忽略文件怎样处理

Setup script 不应打印或写死密钥。需要凭证时使用组织认可的环境变量、系统凭证库或受控注入,并让缺少凭证的错误清楚可见。不要把真实 .env 提交到 Git。

Worktree 需要的非跟踪本地文件可按官方 Worktree 机制另行配置复制范围,但应遵循最小必要原则。含生产密钥的文件不应因为‘方便初始化’而进入每个并行 Worktree。

10

九、与内置 Git 工具怎样配合

Codex 桌面应用在 Local 与 Worktree 旁提供 diff、分块 stage 或 revert、整文件处理、提交、推送和创建 Pull Request 等常用 Git 控件。初始化成功后,可以直接在同一界面检查改动。

应用未暴露的 Git 操作仍可在集成终端完成。回退前先确认变更归属,不要把开发者已有改动当成 Codex 生成内容。并行 Worktree 要使用独立分支避免互相占用。

11

十、初始化失败的排查顺序

先看 Setup script 的第一条失败命令,再核对运行时版本、包管理器、锁文件、网络、代理和系统依赖。确认脚本 cwd 与 Git 根正确,并检查是否错误依赖 Local 目录的缓存。

修复后用新的干净 Worktree 再验证,避免旧目录残留掩盖问题。将常见错误写进项目文档,并让脚本对版本不匹配给出明确提示。

12

十一、一个稳妥的落地清单

选择正确项目根;将配置放入 .codex;Setup script 只做必要初始化;锁定依赖;支持重复运行;按平台覆盖;Actions 聚焦构建与测试;避免秘密和绝对路径;验证并行端口;在干净 Worktree 回归。

更多 Codex 实践可访问 https://gptupcn.com/codex/ 。功能入口与配置结构会随版本更新,实施时应以当前 OpenAI Docs、桌面应用设置和项目实际运行结果为准。

13

十二、怎样兼顾初始化速度与稳定性

Setup script 应优先使用包管理器的锁文件与安全缓存,但不能把缓存命中当成正确性的唯一条件。首次创建、缓存为空和缓存损坏三种情况都要能给出一致结果,必要时提供清理缓存后重试的明确步骤。

把耗时很长但并非每次必需的操作移到独立 Action,例如完整端到端测试或大型资产构建;Setup 只保留新 Worktree 开工所需的最小步骤。这样既缩短聊天启动时间,也保留需要时执行完整验证的入口。

14

结语

本地环境配置的目标,是让每个 Codex Worktree 都能从可预测状态开始。把初始化放进 Setup scripts,把日常命令做成 Actions,再配合内置 Git 审查,可以减少‘在本地能跑、换目录就失败’的问题。

资料

官方资料与延伸阅读

产品界面、价格、额度和规则可能调整,涉及实时信息时请以官方页面与账号内显示为准。

延伸

相关文章

继续阅读同一主题下的文章,可以把购买、支付、套餐、账号和到账问题串成完整流程。

FAQ

常见问题

Setup script 每次聊天都会运行吗?+

官方说明,它会在 Codex 为新聊天创建新 Worktree 时自动运行,用来初始化该工作目录。

Actions 在哪里执行?+

Actions 显示在桌面应用顶部,并在应用的集成终端中运行。

可以把真实 .env 写进配置吗?+

不建议。配置可进 Git,但密钥应通过安全环境变量或凭证机制注入,遵循最小必要原则。