大家有没有这种感觉：网页聊天里的AI不管聊得多好，一旦要真正落盘改代码，它就"隔了一层"。你在对话框里描述需求，它给你一段代码，你复制回去运行，报错了再复制回来，一来一回效率很低。我在过去几个项目里反复折腾AI编程工具，最后固定下来的是Codex CLI这个跑在终端里的AI Agent。它不属于IDE插件，也不是网页对话框，而是直接在项目目录里干活——你告诉它需求，它自己去读代码、写文件、执行命令、看报错、再修，整个闭环都在命令行里完成。这篇文章把Windows + Node这套环境下的完整上手路径写出来，从环境准备、安装登录，到跑通第一个任务、调节配置，最后盘点Windows下我踩过的坑。适合两类人：一是已经在用终端写代码、想把日常杂活交给AI的开发者；二是刚接触AI Agent、想从网页聊天切到命令行实操的人。
1. 为什么是它：终端里的AI Agent到底解决了谁的痛点
1.1 聊天式AI和Agent的区别，不在"聪明"，在"有手有脚"
传统的AI编程辅助，本质是"问答式"的。你问一句，它答一段，主体还是人：人负责理解、人负责动手、人负责验证。这在查函数用法、写小段算法的时候确实够用，一旦需求跨多个文件、涉及环境依赖、需要反复试运行，问答式的效率瓶颈就出来了——上下文要被你手动搬运，报错信息要靠你手动喂回去。
Codex CLI这类Agent最大的不同，是它能自己动手。它可以在工作目录里查看文件列表、读取文件内容、修改文件、执行shell命令。你把需求说清楚，它自己规划步骤，自己写代码，自己跑，甚至看到一个报错之后自己回去改代码再跑。这个循环很像一个新人开发者在干活："看一眼代码，改一处，跑一下，报错就再改。"只不过它的阅读速度和修改速度比人快得多。
我做项目时最常用的场景是：准备测试数据、批量重命名、补注释、写脚本处理脏数据。这些活得写代码，但又不值得认真当一个"功能"来做。以前我都是自己写个一次性的Node脚本，用完就删；现在直接开个Codex会话，用自然语言描述需求，它把脚本写出来、跑完、我验一下结果，完事。省掉的是"从脑子里翻译成代码"的时间。
1.2 它和IDE插件的边界也不一样
很多人会问：IDE里不也有AI插件吗，为什么非要CLI？我的体感是，IDE插件的优势在于"贴身"——它看着你当前打开的文件，适合补全、解释、小范围重构。但它很少主动跑命令，也不会站在整个项目的角度去改多个散落文件。
CLI型Agent的优势是"宽"和"自动化"：
- 它可以同时操作几十个文件，适合批量重构、批量生成。
- 它可以执行命令，比如安装依赖、跑测试、启动服务，然后根据输出来判断下一步。
- 它可以被脚本调用、可以非交互式执行，适合把AI塞进自动化流程里。
所以我现在的习惯是：在IDE里写代码时用补全类AI，遇到"跨文件改造""跑通一个流程""处理一堆脏数据"这类任务，切到终端开Codex。两者不冲突，甚至互补。
1.3 什么人应该先忍住别装
也说句劝退的话。Codex CLI要求你至少看得懂终端的基本操作：cd进目录、看报错、理解路径。如果你从没在命令行里运行过Node脚本，建议先去补二十分钟基础，否则Agent做了什么你完全无感，出了问题也没法判断是该修提示词还是该修环境。它不是一个帮你"跳过学习"的工具，而是一个帮你"省掉重复劳动"的工具——这两者有本质区别。
2. 开工前检查单：Windows + Node 环境最容易出事的三个位置
2.1 Node版本：过低过新都会卡在安装环节
Codex CLI本质是一个npm包，所以最基础的条件是Node.js环境。官方要求Node 20以上，我建议直接上22 LTS。为什么是LTS而不是最新版？因为npm生态里有些依赖对奇数版本、对刚发布的新版本兼容性不够稳，用LTS能少碰很多"我这明明没问题为什么装不上"的诡异情况。
Windows下管理Node版本，我推荐nvm-windows，它和macOS/Linux上的nvm用法几乎一致。安装好之后两条命令：
nvm install 22 nvm use 22装完务必确认一下当前版本：
node -v npm -v这一步看起来糙，但真的能挡掉不少问题。我见过好几个朋友说"Codex安装时报引擎版本不匹配"，结果一查node还是14.x。如果你之前为了其他项目装过老版本Node，且没有用版本管理器，那建议这次直接上nvm-windows重管。
2.2 终端选不对，后面跑命令各种别扭
Windows默认的cmd和老版PowerShell 5.0，在跑现代CLI工具时有两个典型毛病：一是字符编码经常出现乱码（尤其是中文环境），二是对某些命令的解析方式和Unix shell不一致。
我的建议是装Windows Terminal，然后把默认shell设为PowerShell 7，或者直接装Git Bash使用。原因很简单：Codex CLI的命令行交互界面有颜色、有动态刷新的状态，Windows Terminal对这类ANSI转义的支持比老终端好很多；PowerShell 7和Git Bash对UTF-8和路径符号的处理也更接近其他系统。这不影响Codex判断文件，但影响你的阅读体验，以及会话过程中手动输入指令的顺畅度。
如果你打算长期用，顺手把终端编码切到UTF-8：
chcp 65001这个命令只对当前窗口生效，下次开终端要重新执行。介意的话可以在PowerShell profile里加一行，或者直接在Windows Terminal的配置文件里把默认编码改掉。
2.3 Git是隐藏依赖，别等Agent要提交时才装
Codex CLI在运行时会大量调用git来查看文件变更、生成diff、甚至帮你提交代码。它不是"可选依赖"，而是实际工作流的一部分。如果你机器上还没装git，先装好，并且配置好用户信息：
git config --global user.name "your-name" git config --global user.email "your-email"这两行配置不然后面Agent帮你git commit的时候会直接报错，那时候你还得切出会话去配。我习惯在每个准备交给Agent处理的项目里先git init一次，这样它每一步改动我都能用git diff回溯，心里有底。别小看这个习惯——AI写代码偶尔会"自由发挥"得很远，有git的话随时能回滚，没有的话只能手动删改。
另外，如果你打算用WSL下的Linux环境跑（后面第4章会讲到本地沙箱模式为什么依赖它），那在WSL里也要装Node和git，别只装Windows版本。我见过最尴尬的局面是：Windows里一切就绪，切到WSL后node都不存在，然后在那折腾半天环境变量。所以选定一条路就走到底，别混着来。
3. 安装、登录、第一条指令：30分钟跑通最小闭环
3.1 一条npm命令装好，版本校验别跳过
环境就绪后，安装本身简单到离谱。在终端执行：
npm install -g @openai/codex安装完成后，第一步永远是用版本命令验证：
codex --version能正常打印版本号，说明核心安装没问题。如果这一步报错，基本只有两个原因：Node版本不对、或者npm全局目录不在PATH里。后者在Windows上偶尔出现，解决方法是把npm全局安装目录（通常在%APPDATA%\npm）加到系统的Path环境变量里，然后重启终端。
npm下载慢的问题，我给一个通用解法：把registry切到国内公共镜像，下载速度会立竿见影。这个配置对后续所有npm包都生效，不算什么偏门操作：
npm config set registry https://registry.npmmirror.com装完之后不用急着改回来，日常没有影响。
3.2 codex login：十几秒的授权，决定你会不会中途断档
安装包本身不包含"身份"，需要登录一次账号。执行：
codex login终端会显示一条授权链接，并在浏览器中打开登录页。你登录自己的Codex账号，确认授权，然后终端会自动确认成功。整个过程大概几十秒。
这里有两个Windows下常见的小问题：
第一，浏览器没自动弹出来。不用慌，把终端里的链接手动复制到任意浏览器里打开完成授权即可，授权结果会回传。
第二，登录状态有时会因为账号token过期而失效，表现是执行任务到一半突然提示需要重新授权。这不常见，但遇到了重新跑一次codex login就行。我的建议是：别在头一天晚上写好的长任务上刷存在感，开始大任务前先确认登录状态有效。
登录之后，用户目录下会生成一个隐藏目录.codex，里面存放着认证信息和配置文件。Windows下路径是C:\Users\你的用户名\.codex\。后面调整配置、写项目手册都是在这个目录里操作。
3.3 用codex init建立一个"项目使用说明书"
这是很多人会忽略的一步。在项目目录下执行：
codex init它会在当前目录生成一个AGENTS.md文件。这个文件的作用，是给AI Agent看的"项目手册"——项目是做什么的、用什么框架、构建命令是什么、有没有不能动的目录。Codex每次在这个目录里工作时，都会优先读这个文件来理解项目背景。
我的建议是：不要让它保持默认空模板，而是手动维护几行信息，比如"本项目是Express老项目，入口在src/index.js，测试用vitest，node_modules不要动"。你写的越清楚，Agent后续自主干活越少瞎猜。这个文件有点像你给实习生写的第一天入职培训文档，投入很小，省下的沟通成本很大。
3.4 第一条指令，先让它看看这个项目
最小闭环的验证方式很简单：在一个项目目录里，让Codex先只观察、不动手。
交互模式启动：
codex进入对话后输入：
请列出当前目录的结构，并说明这个项目大概在做什么。不要修改任何文件。如果你用的是codex exec一次性执行模式，也可以这样：
codex exec "请列出当前目录的结构，并说明这个项目大概在做什么。不要修改任何文件。"Codex会自己调用命令读取目录，然后给你一份总结。第一次跑通这个流程，意味着安装、登录、上下文读取、响应生成这条链路全部正常。之后就可以开始真正干活了。
4. 它怎么"读懂"并"操作"你的电脑：Codex CLI的运行机制拆解
4.1 核心循环：观察、思考、行动、验证，然后循环
理解Codex CLI，抓一条主线就够了：它是一个循环。它拿到你的自然语言指令后，先把目标拆成若干步骤，然后反复做四件事——观察当前状态、思考下一步操作、调用一个工具执行、根据结果判断是否完成或需要调整。
这个循环在终端里的表现，是它会一条条显示当前正在做什么：查看某个文件、执行某个命令、修改某段代码。你可以看着它一步步推进，而不是一次性甩给你一个结果。这个过程透明性很强，也给了你在中途干预的机会——看到方向不对，直接打断并纠正，比等它跑完再返工效率高很多。
它在代码里实际操作的类型，基本覆盖了四种：读取类（查看文件、列目录）、修改类（写文件、批量替换）、执行类（跑shell命令、安装依赖、跑测试）、以及搜索类（在项目里按关键词找文件）。说白了，你自己在终端里能做的事情，它都能通过调用工具完成。
4.2 工作区边界：它眼里只有当前项目，别指望它管全局
Codex CLI不是"接管你整个电脑"的AI，它的视野和行动范围默认限制在当前工作目录。你从哪个目录启动codex，它就围绕哪个目录工作。这个设计一方面是为了安全，避免它随便读你桌面上的私人文件；另一方面也是为了让上下文更聚焦，不让无关文件干扰判断。
在项目根目录里，它可以自由查看所有子目录和文件（除非你的配置文件里设了exclude排除项）。我强烈建议在大项目里配置排除node_modules、dist、.git这类又大又没用的目录。否则Agent扫描文件列表时可能会慢，也可能在读文件时把一些自动生成的代码当成业务逻辑来分析，导致理解偏差。
4.3 计划和审批：为什么我不建议一上来就全自动
Codex CLI在执行操作前有审批机制，尤其是执行命令和修改文件时，会等待你确认。这个机制决定了它在你的机器上是"有边界的执行者"，而不是"失控的自动机"。
实际使用中有一个授权行为模式的选择，常见的有：让Agent全自动执行、让它先把计划列出来等你批准、或者只在出现错误时向你确认。我强烈建议第一次使用时选"先计划后执行"的模式。你可以通过启动时的参数或配置来控制，比如在交互中输入计划模式，或者首次执行时明确要求"先给出计划，不要执行"。
这个习惯能帮你快速理解Agent的思考方式：它打算先看哪个文件，打算用什么方案，有没有理解偏。等你对它的风格熟悉了，再逐步放开授权级别不迟。
4.4 云端执行与本地执行：两种运行模式的取舍
Codex CLI有两条执行路径。一种是云上执行模式：AI在远程沙箱里分析代码、运行命令，然后把结果同步回本地目录。好处是你本机不需要装很多依赖，环境更干净；缺点是网络请求来回有一定延迟，而且如果你本地环境的差异会影响结果（比如依赖只在本地装过），它可能"跑通了但你没跑通"。
另一种是本地沙箱模式：AI直接在本机执行命令和修改文件，更像一个真人在你的终端里操作。好处是和工作区实际环境完全一致，适合跑构建、跑测试这类依赖本地环境的操作；缺点是在Windows原生环境下，完整的沙箱隔离能力受限，通常需要借助WSL或容器来获得可靠的本地沙箱隔离。
我的建议是：日常改代码、写脚本、批量处理文件，用云端模式没问题；一旦涉及"跑构建、跑测试、起服务、看运行结果"，优先切到本地模式。这也是为什么我在第2章强调WSL可装可不装，但真高频使用后大概率会需要。
5. 首个实战：让Codex把一个乱糟糟的下载目录整理成规整分类
理论说完了，来一个完整的实战。这个案例我选得很"日常"：整理一个乱糟糟的下载目录。它不涉及复杂的业务逻辑，但足够展示Agent工作的完整闭环：理解需求、制定计划、写代码、运行、遇到报错、自我修复、验证结果。
5.1 准备实验场地
我先创建一个模拟目录，里面放了几类文件扮演"下载文件夹"：
mkdir codex-demo cd codex-demo mkdir data # 在data目录下放一些文件：几张图片、几个文档、两个压缩包文件命名故意造得乱一点，比如photo1.jpg、微信图片_20250101.png、项目说明final(2).docx、报告数据.xlsx、backup-2024.zip、temp.zip——什么都混在一起。
目标也很明确：按扩展名分类（图片、文档、压缩包），分门别类放进独立的子目录；文件名统一加上当天日期前缀；原文件不能被删除，只能移动。
5.2 给Codex下达需求，先要计划
启动交互模式，输入：
请扫描当前项目下的data目录。这个目录里混了很多种类型的文件，请写一个Node脚本，把它们按类型移动进不同的子目录：图片（jpg/png/gif）放到images，文档（docx/pdf/txt/xlsx）放到docs，压缩包（zip/rar/7z）放到archives。移动后的文件名加上当天日期前缀，例如2025-01-08_photo1.jpg。要先给出你的执行计划，不要直接改动文件。注意我特意在最后加了"先给出执行计划，不要直接改动文件"。这是第一次使用时的安全操作，先看它准备怎么干，再放行。
Codex给出的计划基本是：先列目录确认文件清单，然后写脚本遍历文件，用正则或扩展名判断类型，用fs.rename移动文件，并测试运行。它还会提一句"移动前先对每个文件确认扩展名"，这个细节说明它确实先看了目录里有哪些文件，而不是凭空想方案。
5.3 批准执行，然后它踩了一个经典的Windows坑
我确认计划后，说"按这个方案执行"。Codex开始写脚本、运行。
第一次运行报错了。错误信息很眼熟：
Error: EXDEV: cross-device link not permitted, rename 'C:\...\data\photo1.jpg' -> 'D:\...\images\2025-01-08_photo1.jpg'这不是它代码写错了，而是Windows文件系统的特性：如果源文件和目标目录不在同一个磁盘分区（C盘和D盘），fs.rename不能直接跨盘符移动文件。如果你用过Node写文件操作工具，这个坑大概率也遇到过。
Codex看到报错后，没有停下来等我来处理。它自动读取了报错信息，判断是跨盘符问题，然后把方案改成"先复制文件到目标目录，再删除原文件"的方式重试。第二次运行成功，data目录下的文件被整理到位，控制台打印出每个文件移动前后的路径。
5.4 校验结果，并复盘这个过程中发生了什么
我手动打开目录检查：images、docs、archives三个文件夹出现，文件各归其位，文件名带上了日期前缀。原文件没有丢失，脚本没有误删，格式完整。
这个案例真正值得注意的不是Codex"会写脚本"——脚本本身不复杂。而是它展现出了一种完整的工作方式：它不是一次性甩给你一个"你应该这样写"的答案，然后让你自己去跑；而是自己推进了"看目录、写脚本、运行、识别报错、修复方案、重跑、验证"这一整个闭环。你的角色从"执行者"变成了"审批者"。
你只需要在它每次请求批准时判断"这个操作是否安全、方向是否对"，剩下的重复劳动它包了。
5.5 复盘：我作为使用者做了什么关键判断
我不是全程躺着。在它运行报错后，我本来想提示它"换个分区试试"，但发现它已经在自我修复了，于是闭嘴等结果。如果它连续修两次还不行，我才会介入给出方向。
这就是人机协作该有的节奏：AI负责执行，人负责判断边界和方向。它每次请求执行命令时，我会扫一眼将要执行的命令——有没有rm -rf、有没有超出工作目录的路径、有没有明显离谱的权限操作。确认没问题就放行。信任是逐步建立的，别一开始就全自动，也别永远不敢放权。
6. 从"偶尔能用"到"日常顺手"：配置与提示词调教
跑通第一个任务后，你大概率会希望它更像"自己的工具"而不是"通用的AI"。这一章聊怎么调教。调教分两个层面：配置文件层面的持久化设置，以及会话中提示词层面的沟通技巧。
6.1 config.toml：你的持久化偏好清单
Codex的主要配置文件是.codex目录下的config.toml。Windows下路径为C:\Users\你的用户名\.codex\config.toml。没有就手动创建。我常用的几个配置项整理如下：
| 配置项 | 作用 | 我推荐的设置 |
|---|---|---|
| model | 指定使用的模型标识 | 保持默认即可，值以你账号可用的模型为准 |
| sandbox_mode | 运行模式：云端或本地沙箱 | 默认云端；需要本地跑构建时切换本地 |
| auto_approve_behavior | 自动审批行为 | 新手阶段设为先出计划；熟练后再放宽 |
| include | 额外让Agent读取的路径 | 保持默认即可 |
| exclude | 排除不扫描的目录 | 必须加入node_modules、dist、.git |
| 环境变量 | 让Agent在运行命令时继承的额外环境 | 按项目需要填写 |
其中exclude是要重点关注的一项。在一个大型前端项目里，node_modules动辄十万个文件，不排除掉的话Agent每次列目录都慢半拍，还有可能把依赖库里的代码当成项目代码来分析。排除后它的上下文干净很多，回答质量和速度都会上去。
6.2 AGENTS.md：把你项目的"潜规则"写在明面上
我在第3章提过codex init生成的AGENTS.md，这里展开讲。它本质上是给Agent读的项目说明书。你不在场时，它靠这个文件来判断"什么能做、什么不能做"。
我维护这个文件的大致模板是：
- 项目简介：两三句话说明项目是做什么的。
- 常用命令：启动命令、测试命令、构建命令，直接写成可复制的形式。
- 目录约定：哪些目录存放源码、哪些是构建产物、哪些千万别删。
- 代码风格：分号还是无分号，单引号还是双引号，缩进几格。
- 明确禁区：比如"不要修改package.json版本号""不要动数据库迁移文件"。
写这个文件的技巧是：把自己平时在群里跟同事反复叮嘱的话全写进去。Agent和同事的区别是，同事问一次就记住了，Agent可能每次干活前都要靠这个文件补记忆。所以越具体越好，宁可啰嗦不要留白。
6.3 提示词的"四件套"话术
在会话里给Agent下达任务时，我总结了一个四件套结构，基本不出错：
- 背景：这个项目是什么，相关文件在哪。
- 目标：你要它最终交付什么。
- 约束：什么不能碰、什么必须保留、有没有兼容性要求。
- 验收标准：怎么算做好（比如"跑npm test全部通过"）。
举例对比一下。差的提示词："帮我优化一下这个下载功能。"——它不知道优化到什么程度，也不知道哪些方面不能动。
好的提示词："这个项目在src/utils/download.js里有一个下载逻辑，目前并发下载10个文件时偶尔超时。请引入p-limit做并发控制，把并发数限制在5，保持现有函数签名不变，确保调用方不用改代码。完成后跑一下npm test确认没破坏现有功能。"
后者它基本一次就能正确完成。前者它会犹豫，然后问你一堆问题。在命令行交互模式下也能追问，但一来一回多花时间。不如一开始就说清楚。
6.4 多轮纠错：怎么让它从错误里自己爬出来
Agent会犯错，但犯错后的处理方式和人协作很类似：把错误信息贴回去，让它分析。你不需要自己看懂报错，只需要告诉它"运行报错了，输出在下面，你分析一下原因然后修复"。它会自己定位到报错那行，判断是环境问题、代码问题还是依赖问题。
这里有个小技巧：如果它在同一个问题上连续失败两次以上，不要继续让它自己撞墙了。这时应该主动补充上下文，比如"这个函数是从第三方库里引入的，不是自己写的，别去改那个库"或者"这台机器上npm install需要额外参数"。很多情况下，它失败不是因为能力不够，而是因为它缺少一个只有你知道的上下文信息。你把这个信息补给它，问题往往立刻解决。
6.5 MCP：让Agent长出新的"器官"
Codex支持通过MCP（Model Context Protocol）扩展能力。你可以把它理解为给Agent接入新的工具接口：比如接一个数据库操作接口，它能直接查表看数据；接到浏览器工具，它能操作网页；接到某个内部API的SDK，它能直接调接口测试。
配置方式是在config.toml里声明mcp_servers，指定启动命令和参数。如果你没有明确需求，这个功能可以先放一放。我的建议是：先用一个月纯命令行版本，搞清楚它的工作习惯，再考虑接MCP。一上来就接一堆扩展，容易让你分不清能力边界到底在哪，出问题也不知道是核心功能还是扩展的锅。
7. Windows下踩坑实录：这些问题我修了很久
最后是Windows环境下的常见问题汇总。这一部分是我实际使用中花时间最多的地方，写出来帮你少绕路。
7.1 安装时报"engine"相关错误
现象：npm install -g @openai/codex报错，提示要求Node版本高于某个值。
原因：机器上的Node版本太旧。
解法：用nvm-windows切换到22 LTS。不要手动去改包内的engine字段，那是在制造更大的坑。
7.2 PowerShell执行策略拦住了脚本执行
现象：Codex在本地模式下尝试跑脚本时，被PowerShell的ExecutionPolicy拦下来。
原因：Windows PowerShell默认执行策略偏向保守，禁止运行未经签名的脚本。
解法：在PowerShell里查看执行策略，必要时调整为当前用户可运行本地脚本：
Get-ExecutionPolicy -List Set-ExecutionPolicy -Scope CurrentUser RemoteSigned如果你用的是Git Bash，这个坑一般不会碰到。这也是我推荐用Windows Terminal配PowerShell 7或Git Bash的原因之一。
7.3 终端中文乱码
现象：Codex输出的中文、或者脚本打印的中文日志，在终端里显示成乱码。
原因：老式终端默认按GBK（代码页936）解码，而大部分现代工具输出UTF-8。
解法：切到Windows Terminal，执行chcp 65001切换UTF-8代码页。如果用小众终端模拟器，去它的设置里找编码选项，强制UTF-8。这个问题不影响Agent实际逻辑，但影响阅读，也影响你复制报错信息（复制出来是乱码，喂回给Agent它也看不懂）。
7.4 本地沙箱模式启动失败
现象：尝试使用本地沙箱模式时，Codex提示当前环境不支持或需要额外组件。
原因：Windows原生环境对OS级别沙箱隔离的支持较弱，不像Linux那样有成熟的内建沙箱机制。
解法：两条路。一是安装WSL，在WSL里的Linux环境启用本地沙箱模式；二是不开本地沙箱，继续用默认的云端执行模式。除非你频繁需要在本地跑构建和测试，否则默认云端模式完全够用。
7.5 跨盘符移动文件的EXDEV错误
现象：Agent写的文件移动脚本，报EXDEV: cross-device link not permitted。
原因：Windows下不同磁盘分区之间，fs.rename等基于同一文件系统设计的操作不能直接用。
解法：这是代码层面的问题，直接让Agent改成"复制到目标位置后再删除原文件"。如果它没自动意识到，你可以把这句错误信息贴给它，加一句"注意这是Windows跨盘符问题"，它马上就能修正。
7.6 大项目扫描慢，上下文越混越乱
现象：在大型前端项目里，Agent列目录很慢，有时还会答非所问，把依赖代码当业务逻辑分析。
原因：没有排除node_modules等大目录，Agent扫描文件列表时被无用信息淹没。
解法：在config.toml的exclude里加node_modules、dist、.git、coverage等目录。改完配置后重启Codex会话，体感上"快了不是一点半点"。
7.7 授权状态失效，任务跑到一半中断
现象：长任务执行到中途，终端提示需要重新登录授权。
原因：账号登录凭证过期。
解法：重新跑codex login。建议在开始一个长任务前先确认登录状态，或者在配置里了解清楚凭证的有效期机制，这一点不同账号策略可能不同。至少要有心理准备，别在大任务跑到最后一步时被登录打断。
7.8 让Agent读不到某些文件
现象：Agent说找不到某个文件，但文件明明就在项目里。
原因：可能是被exclude规则排除了，也可能是当前工作目录不对。
解法：先看当前会话启动时所在的目录路径，再看配置文件里的exclude有没有把该目录排除掉。排查顺序是：先确定工作目录、再查配置、最后才是问Agent"你是不是看漏了"。大部分情况不是它看漏，是上下文边界没设对。
最后再补一句实际体会
用Codex CLI跑了这段时间，我最深的感受是：它的价值不在于"AI能写多少代码"，而在于把"从想法到落盘"之间的距离压缩到了极致。以前我有个小需求，想一下实现思路、写代码、调试、验证，至少半小时；现在同样是半小时，我可以让Agent同时做三四件事，我只负责验收。
我现在的固定流程是：进入项目目录、写AGENTS.md、让它先出计划、批准执行、有问题贴回给它的报错提示。这套流程跑顺之后，它已经不只是工具，更像一个随叫随到、不会抱怨、指哪打哪的"虚拟同事"。
如果你刚开始用，我这篇里最想让你记住的一句话是：不要急着把所有权限交给它。先让它多"汇报"、多"请示"，你多观察几次它的工作方式，再决定哪些环节可以放权。安全边界这种东西，宁可保守一点，后面再放开也不迟。
