根本原因是调试前缺乏对工作区状态、修改边界和验证路径的显式约束；需先清理git暂存区、用/plan分阶段分析、限定可写文件、禁止顺手优化，并严格验证改动范围。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
调试时Codex频繁修改非目标文件，导致测试失败、逻辑错乱或需要反复回滚，根本原因不是模型理解力不足，而是调试任务启动前缺乏对工作区状态、修改边界和验证路径的显式约束。
先确认当前工作区是否干净
执行 git status --short 查看未提交文件列表；若输出非空，说明已有本地改动。Codex会把这部分内容当作“当前项目状态”的一部分，可能将你的临时调试代码误判为待修复逻辑，进而覆盖或联动修改。
运行 git diff --cached 检查已暂存但未提交的内容；如果存在与本次调试无关的变更（比如上一个PR的遗留修改），必须先 【git stash 或 git commit】 清理暂存区，否则 Codex 生成的 diff 会混入历史改动，无法准确识别本次调试的真实影响范围。
用 /plan 强制分阶段：分析→方案→执行
第一步，输入指令：
先不要改任何代码。请检查登录后跳回登录页的问题，重点定位：1. auth token 是否在路由守卫中被错误清空；2. useAuth hook 的依赖数组是否遗漏；3. 浏览器 localStorage 中的 token 字段名是否与新接口不一致。输出涉及的文件路径和最可能出问题的三行代码位置。
第二步，等它返回分析结果后，你确认无误再输入：
按上述分析，在 src/hooks/useAuth.ts 和 src/router/guards.ts 中做最小修复。只修改判断逻辑，不调整 import 排序、不重命名变量、不补全 JSDoc。修复后运行 npm test -- --testPathPattern=auth。
这一步的关键是把“读”和“写”彻底断开。很多调试失败，就败在没看清问题根源就让 Codex 直接动代码——它会基于常见模式猜测，而你的项目很可能用了反模式写法。
限定可写文件并禁用自动重构
方法一：在指令开头明确声明允许修改的文件列表
通过本地 MCP 桥接程序将 QQ 邮箱接入 Codex，配置所需的.env凭证信息、注册 MCP 服务端，并完成收件箱读取与邮件发送的全流程测试。适用场景：用户需要将 QQ 邮箱连接至 Codex、让 Codex 读取 / 发送 QQ 邮件、安装 / 修复qq_mail MCP 服务端，或是在 Windows 系统上排查 IMAP/SMTP 配置故障时，执行以上操作。
本次调试只允许修改以下两个文件：
• src/hooks/useAuth.ts
• src/router/guards.ts
其他所有文件（包括 package.json、vite.config.ts、所有 .test.tsx）仅限读取，禁止写入、禁止新增、禁止删除。
方法二：加入强约束语句防止顺手优化
请严格保持现有代码风格：不调整缩进空格数、不合并重复 import、不将 var 改为 const、不添加 eslint-disable 注释。如果发现某处逻辑明显冗余，请跳过修改并标注“此处需人工评审”，不要自行重构。
【“不要顺手优化”这句话必须写进每条调试指令】 否则 Codex 会在修复 token 校验时，顺手把整个 router 配置从 createRouter 改成 useRouter + 动态 import，这种改动完全脱离调试目标。
执行后立即验证改动范围
① 运行 git diff --name-only —— 如果输出里出现 src/components/LoadingSpinner.tsx 或 tests/e2e/login.spec.ts，立刻中止后续操作。
② 对每个被修改的文件，逐行比对 git diff 输出：重点关注是否新增了 console.log、是否替换了原有条件分支、是否在 return 前插入了未声明的 await。
③ 执行 Codex 提供的验证命令（如 npm test -- --testPathPattern=auth），观察是否新增 failed test。如果失败用例名与本次调试目标无关（例如 “should render sidebar when user is admin”），说明它误改了权限控制模块。
