确认框跟着手指走：改两行文件问一次，跑一条测试又问一次。有人嫌烦，想一键全开。也有人怕它摸到密钥目录，又不敢放。官方 Security 页把权限模式、sandbox 和凭证存放写在一起。先把「会话默认从哪档起步」对上，再谈要不要收紧，比对着弹窗瞎点省事。
会话默认从哪档起
Security 页写得很直：交互式终端和 VS Code 会话，内置起点是 Auto mode。Manual、别的界面、以及改起始模式的设置，文档用 “Which mode a session starts in” 那一节分开说明。官方页把 Auto 标成上述两种交互场景的默认起点。
两档差别可以记成「谁来拦第一道」：
- Manual：会话先按只读权限起。改文件、跑测试、执行命令前会问你，你可以批一次或长期允许。内置的只读命令，比如
ls、cat、git status，可以不问就跑。 - Auto：另有一个分类器模型代你审动作，把判定为不安全的拦下。你自己写的 ask / deny 规则仍然生效，组织也可以关掉 Auto。
Auto 并不是「关掉所有确认」。文档还单独写了 Accept Edits：自动批准工作目录内的文件编辑，以及 mkdir、touch、rm、mv、cp、sed 这类固定的文件系统 Bash 命令。别的 Bash、以及工作目录外的路径，照样会问。想少打扰，更稳的是按项目加 allow 规则，或用 /sandbox 划边界，而不是冲着「全部免确认」去。
分类器拦下动作时会通知你，最近被拦的条目可以在 /permissions 里看到，必要时再批准重试。Best practices 里把两端的代价写得很白：Manual 太密容易点到手麻。bypassPermissions 只适合一次性容器这类可丢弃环境——日常开发别当默认。会话里也可以用 Shift+Tab 在权限模式之间切换，或从 shell 用 --permission-mode manual 起会话。
/sandbox 管的是 Bash 边界
权限模式管的是「要不要问人」。Bash 若还要文件系统和网络隔离，用 /sandbox 配置沙箱边界，让 Claude Code 在划定范围内少弹窗也能自己干活。Manual 下还有工作目录边界：文件工具读写启动目录及其子目录之外时会先问。你批准过的 Bash 仍可能写到当前用户权限够得到的任何地方。要把 Bash 也限在操作系统层，得把 sandbox 打开。
网络侧单独看一眼也行。Manual 下，curl、wget 这类拉网页的命令默认不会被自动批准，表现和其他非只读 Bash 一样会提示。想彻底禁，写进 permissions.deny。文档提醒：deny 规则匹配的是「写成什么样的命令」。不依赖命令文本的网络隔离，要看 sandbox 的网络策略。
敏感目录常见做法是 deny 规则拦 Read，再配合 sandbox。官方例子里对 .env 一类路径的 deny，在 Auto 和更宽松的模式下仍然生效。规则匹配的是工具调用，不是「意图」：Read 规则能挡住常见的读文件命令，挡不住任意脚本自己打开文件。WebFetch 的域名 deny 也不等于挡住同域名的 curl，除非 sandbox 也开着。严格 sandbox 模式下，被拦命令不能再请求「出沙箱重试」，适合密钥目录、生产配置副本这类目录。
凭证放哪
Security 页的 Credential Management：API key 和 token，macOS 有 Keychain 就进 Keychain。Linux 写在 mode 0600 的文件里。Windows 则落在继承当前用户配置目录访问控制的文件里。本机多用户、共享开发机时，先确认文件权限没被放宽。
装好后若弹窗节奏不对劲，可以按这个顺序试：先确认当前是 Auto 还是 Manual。敏感路径用 deny 钉死。Bash 需要隔离再开 /sandbox。高频且确实安全的命令再逐条放进 allow。整页「全部批准、永不询问」留给可丢弃环境，别当成日常省事开关。命令行里密码会不会进进程列表，是另一条排查线，这篇只谈权限 UX 和 sandbox。
你们项目默认留 Auto，还是一进来就切 Manual？敏感目录是靠 deny，还是主要靠 sandbox？