把 MiniMax Code 的权限一次性全部允许，最容易留下的是“说不清它能做到哪一步”的问题。更稳妥的拆法是：读文件可以放行，但要能核对读了哪些文件；跑命令保留逐条确认，并把执行目录锁在项目内；改代码先让 Agent 给出改动计划，审批后再落盘。下面按设置、放行、确认、审批、回滚五步说明，权限选项名称以你实际界面为准。

授权要分开给，目的不是让 Agent 少干活，而是让每次越界都能被看见。读操作可放行但保留文件清单；命令执行默认确认并限定工作目录；写操作先审计划再比对 diff。收紧或放宽配置后，用一次故意越界的请求和日志回看确认范围，再决定是否恢复默认授权。

在设置页确认三类动作各自的开关位置

先不要急着改配置，先找到设置入口。常见路径是“设置 / 偏好设置 / Agent 权限 / 工具权限”，也可能放在会话侧边栏的权限面板里。进入后重点看它是否把权限拆成读文件、执行命令、写文件三档，而不是只给一个总开关。如果界面只有“允许全部工具”，建议先不要长期开启，改用逐次确认或按会话授权。

把三类动作的默认状态记录下来，后续回滚才有参照。可以用表格或截图记录：动作类型、默认值、允许范围、是否需要确认、配置存放位置。通用配置骨架如下，字段名仅作示意：

permissions:
  file_read: allow
  command_exec: ask
  file_write: ask
  workspace_root: /path/to/project
  audit_log: true

如果设置页还提供“工作区根目录”“命令超时”“网络访问”等附加项，也一并记录默认值。记录完成后先不做大改，只确认读、执行、写三档分别对应哪个开关，避免后面把“读文件放行”误当成“所有工具放行”。

只读类操作放行并用文件列表验证

读文件通常风险较低，可以先放行，减少每读一个文件就打断一次的情况。放行时建议同时加上目录范围和敏感文件排除，避免把项目外的路径也纳入默认读取范围。配置骨架可以写成：

tools:
  read_file:
    mode: allow
    scope:
      - ${WORKSPACE}/**
    deny:
      - '**/.env'
      - '**/*.pem'
      - '**/secrets/**'

替换项是工作区路径和需要排除的文件模式。放行后不要只观察“有没有报错”，要让 Agent 输出已读文件清单，提示词可以用：

请只做读取，不要修改文件。列出你本轮读取过的每个文件的绝对路径和读取目的，按目录分组；没有读取的文件不要列。如果读取被拒绝，也请说明拒绝原因。

拿到清单后，与实际目录核对：路径是否都在工作区内，是否出现 .env、密钥、日志等不该读的文件，清单里的文件是否真实存在。可以用版本控制或文件列表辅助比对，例如：

git ls-files | sort
find . -maxdepth 2 -type f | sort

核对结果不一致时，先检查是 Agent 漏报、目录范围写错，还是排除规则没有生效。读操作放行不等于可以忽略清单，清单本身就是授权范围的证据。

命令执行保留确认并限定工作目录

命令执行最容易把影响带出项目目录，建议默认保留确认，不要和读文件共用同一个放行开关。限定工作目录的通用写法是在命令工具配置里指定 cwd，并配合允许前缀和拒绝模式：

command:
  mode: confirm
  cwd: /path/to/project
  allow_prefix:
    - npm test
    - python -m pytest
    - git status
  deny_patterns:
    - sudo
    - rm -rf
    - '> /etc/'

允许前缀只用于明显低风险、可重复执行的命令；其余命令仍然逐条确认。执行前的确认提示至少应包含：完整命令行、实际执行目录、触发原因、超时时间、是否可能访问网络、会影响哪些文件。只显示“运行命令”四个字，不足以判断风险。

越界执行的识别方法：看确认提示里的执行目录是否为项目根目录，看命令中是否出现绝对路径、上级目录跳转或切换到系统目录；执行后检查审计日志里的 cwd 和实际路径。也可以在项目内执行 pwd、realpath 这类命令做对照：

pwd
realpath ./some-file

如果日志中的工作目录不在项目内，或命令里出现 cd /、写入系统目录、下载后直接执行等模式，建议拒绝本次执行，并把该模式加入拒绝规则。命令执行保留确认会增加操作次数，但比事后排查越界写入更可控。

写文件前要求先给出改动计划

写操作不要从“直接改”开始，改成“先审计划、再执行”。给 Agent 的提示词可以固定为：

修改前先只输出改动计划，不要写文件。计划必须包含：
1. 要改的文件路径
2. 改动原因和预期行为
3. 具体修改点
4. 风险与回滚方式
5. 需要运行的验证命令
等我回复“批准计划”后再执行。

审批话术不需要很长，但要明确范围。例如：

计划已读，批准修改 A、B 两个文件；不要动 C；完成后给出 git diff `--stat` 和关键改动片段。如果实际改动超出计划，先停下来说明原因。

计划与实际 diff 不一致时，先不要继续叠加修改。处理顺序可以是：停止写操作，保留工作区，要求 Agent 解释多改的文件；用版本控制查看差异，确认哪些文件不在计划内；如果差异来自误改，回退本次未提交改动或让 Agent 按原计划重做。写文件授权应保留“先计划、后审批”的节奏，而不是审批一次就长期放开整个目录。

用一次回滚验证授权范围是否生效

配置改完后，不要只看开关显示。建议做一次可控的越权测试：让 Agent 读取工作目录外的文件，尝试执行切换目录后的 pwd，或向项目目录外写一个临时测试文件。测试请求可以写成：

请读取工作目录外的 ../outside-test.txt，并说明是否被拒绝。
请在当前工作目录执行 pwd，然后尝试 cd / 再执行 pwd。
请把测试内容写入 /tmp/minimax-auth-test.txt，不要写入项目目录。

观察点包括：是否弹出确认或直接拒绝，拒绝理由是否说明超出工作区，审计日志中的 cwd 和文件路径是否真实，读文件清单里是否出现外部路径。验证时尽量使用同一会话、同一工作目录，避免把上下文差异误判成权限差异。

回退到默认授权的步骤：先恢复之前记录的默认配置，删除新增的放行项，把执行和写入改回确认或拒绝；重新加载配置或重启会话；再重复同一组越权测试，确认行为回到默认。不同版本的入口名称可能不同，以实际界面为准；如果回退后仍然放行，优先检查是否有会话级临时授权没有清除。