担心 Step Code 在终端里改到不该改的文件，判断依据不是它的说明文字，而是三件能在本地验证的事：启动时认定的工作根目录、写动作的确认策略、以及被排除路径的拒绝规则。这三件事分别对应“它把哪个目录当自己的地盘”“哪些动作会停下来等你放行”“越界请求长什么样”。先跑一遍这些确认动作，再决定要不要放开使用。

Step Code 的权限边界由三件事决定：启动时认定的工作根目录、写动作的确认策略、被排除路径的拒绝规则。读操作通常不弹确认，所以别把“没提示”当成“没读”，要看会话日志里的工具调用记录。稳妥做法是把工作根限制到具体子目录，用版本控制差异核对实际落盘，发现越界先定位再用 git restore 回退。

看默认工作目录和可读范围

多数终端里的编码代理，工作根来自启动进程的当前目录，也就是 pwd 打印的那个路径。在仓库根启动，工作根通常是整个仓库；在 src/api 这类子目录启动，工作根可能是该子目录，也可能是向上找到的仓库根——不同实现处理不同，需要结合环境用行为确认，别假设。

确认办法：先执行 pwd，再让 Step Code 读一个仓库根下的文件和一个仓库外的文件，比如 /etc/hosts 或同级目录下的另一个项目。工作根内的子目录通常默认可读，不会逐次询问；工作根外的路径，常见表现是拒绝并说明超出范围，或者要求你显式确认。

• 只读范围的表现：读操作一般不弹确认，所以“没提示”不等于“没读”。想确认它读了什么，看会话日志里的工具调用记录，比看界面更可靠。
• 可读不等于可写：能打开 ../infra/terraform 里的文件，不代表能改，写权限通常是单独一档。

如果启动时 pwd 和你以为的项目根不一致，先停下，改到正确目录再启动，这一步比后面调配置省事。

分清需要确认的写动作和直接执行的动作

三类动作的提示强度通常不一样。写文件一般会先给出目标路径和改动内容（new file 或 diff 形式），等你确认；删除通常单独提示，措辞更重，因为删除往往不在版本控制的可恢复范围内；执行 shell 命令则取决于允许列表——命中允许列表的直接跑，没命中的停下来确认。

• 写文件：提示里能看到完整路径和新增、修改行数，确认前先看路径是否落在预期目录。
• 删除：即使是工作根内的文件，也建议看清是 rm 单文件还是带通配符的批量删除。
• 执行命令：git status、ls 这类只读命令常被放行；git clean、mv、chmod、管道到 sh 的写法通常会拦下来。

确认与拒绝的操作方式以界面提示为准，常见是“允许本次 / 允许本会话 / 拒绝”三档键盘选择。拒绝时如果界面支持附加说明，把原因写清楚，例如“这个路径不要在本次任务里改”，比单纯按拒绝更能减少后续重复试探。需要留意的是，“本会话全部允许”会覆盖后续同类动作，如果任务涉及多个目录，建议逐个确认，不要图省事一路放行。

把改动范围收窄到指定子目录

最直接的办法是换启动目录：先 cd 到目标子目录再启动，工作根自然收窄。如果实现提供了显式的工作目录参数，也可以用参数指定，参数名以 `--help` 输出为准，常见形式是 `--cwd` 或 `--project-dir` 一类。

再用排除列表处理“必须能读、但不该写”的目录，比如密钥、基础设施配置、CI 脚本。下面是一个通用配置骨架，字段名和层级需要按你实际版本替换，不要直接照抄：

{
  "workspace": "./src",
  "readOnly": ["./docs", "./.github"],
  "deny": ["../infra", "./secrets"],
  "requireConfirm": ["shell.write"]
}

被排除或只读目录的表现通常是：写入直接被拒绝，不进入确认流程；读取仍可进行。验证范围是否生效，用一个可回退的小文件试探最稳——让 Step Code 在排除目录里创建一个空文件，看它是否被拒；再让它写一个工作根内的文件，确认正常路径没被误伤。两侧都试过，才算确认配置真的起作用。

在版本控制里核对实际落盘的文件

确认动作和配置都有可能被漏看或多点一步，最终以磁盘为准。任务结束后，在看改动前先跑一遍清单：

git status `--porcelain`
git diff `--stat`
git ls-files `--others` `--exclude-standard`

第一条给未跟踪和已修改文件，第二条给改动行数分布，第三条专门列新增文件——新增文件最容易越界，因为 git diff 默认不显示它们。接着按目录过滤差异：

git status `--porcelain` | grep '^.. *src/'
git diff `--stat` -- ./src ./tests

发现改动落在预期目录之外，先定位再回退。已跟踪文件用 git restore <path>，旧版本可用 git checkout -- <path>；未跟踪的新增文件先用 git clean -n <path> 预览要删的东西，确认没误伤再执行 git clean -f <path>。回退前把越界路径记下来，同时回到上一节收窄工作根或补上排除规则，否则同一个越界动作下次还会出现。