Codex App 负责项目和任务工作区，编辑器负责阅读、编辑和验证代码；两者可在同一项目中分工。
Codex App 是桌面项目工作区，适合组织任务、查看过程和审查改动；IDE 则适合在具体文件中阅读、编辑、调试和运行本地工具。两者可以在同一个项目中配合，但不应让两个入口同时对同一批文件执行未经审查的修改。先明确谁负责探索和计划，谁负责细节编辑和最终验证，能降低上下文混乱与重复改动。
在 Codex App 中选择项目副本，先提出只读任务，例如梳理模块结构、定位某个错误的相关文件、准备改动计划。得到结果后，回到 IDE 打开被引用的文件，核对业务逻辑、依赖和本地运行状态。若需要修改，可在 Codex App 中限制修改范围，也可由开发者在 IDE 中完成；无论选择哪种，都应在最后统一查看差异和测试结果。
例如修复接口返回异常时，先让 Codex App 列出调用路径和可能原因，不改文件；在 IDE 中复现问题并补充缺失信息；再创建一个只允许修改指定模块的任务；最后在 IDE 中运行与该模块相关的检查。这样每个工具都承担它擅长的部分，项目负责人仍能清楚知道改变了什么。
第一，不要让 App 和 IDE 的不同任务同时改同一文件。第二，不要把 IDE 当前打开文件误当作 Codex App 已选项目范围，进入任务前仍要确认目录。第三，不要只看自然语言总结而不看差异；最终合并前应由开发者在熟悉的编辑器中阅读改动、运行测试并确认业务影响。
对于团队项目，可在任务描述中注明“只做计划”“只读本次差异”“不修改配置目录”等限制，并约定审查由谁完成。这样即使成员使用不同 IDE，也能复用同一套项目范围与验收标准。
本页不指导在 IDE 终端安装 Codex CLI，也不把某个编辑器扩展描述成 Codex App 的必要条件。尚未下载 Windows 客户端时回到下载页；已进入项目但不会写任务时看基础教程；需要比较 App 与 Cursor、Claude Code 等不同入口时进入对比页。
从 Codex App 交给 IDE，或从 IDE 交给 Codex App 时，至少保留项目版本、处理目录、已经确认的事实和下一步验证动作。比如“当前在 release 分支；只检查 src/payment；已确认超时发生在重试分支；下一步在 IDE 复现并补测试”。这样下一位接手者不必重新猜测任务范围，也能知道哪些结论尚未验证。
对修改任务还应写明是否允许写入、是否需要先给计划、是否必须由某位成员审查。若 App 只用于分析，就在任务中明确“不要改文件”；若 IDE 中已有本地未提交改动，也先说明这些改动是否属于任务上下文。清楚的交接记录能防止工具读取旧状态或覆盖人工正在处理的内容。
探索项目、整理风险、准备改动清单时，可以先在 Codex App 中完成；实现细节、断点调试、运行本地测试时，通常回到 IDE 更自然；合并前则在一个明确的审查位置统一查看差异。这个顺序并不要求固定使用某个品牌，而是为了避免项目工作区、编辑器文件和最终提交之间失去责任边界。
当项目规则变化时，也应同步更新任务模板与 IDE 侧的审查约定，防止旧流程继续影响新的项目范围。
每次交接后都由接手者确认当前范围即可。
适合正在处理本页标题所述问题的 Codex App 用户。
可按页面底部的相关入口继续完成下载、安装或使用。
按你的当前问题继续阅读，避免在安装、账号和项目设置之间来回跳转。
