Claude Code免确认模式的边界与隔离实践
文章解释跳过权限提示的参数与bypassPermissions模式的对应关系，讨论仍受限制的操作及替代模式。作者称已在一次性Docker容器中，针对Claude Code 2.1.304完成24次测试，并建议仅在受限环境中以非root用户运行。
原文暂未完整获取，基于公开信息的快读
Claude Code 跳过权限确认后，自动化任务能少一些人工介入，但执行边界也更需要提前划清。dev.to 的一篇文章讨论了相关参数、bypassPermissions 模式及隔离实践。作者称，已在一次性 Docker 容器中针对 Claude Code 2.1.304 完成 24 次测试；目前只有摘要，具体测试过程和结论尚未完整可见。
目前能确认什么
文章解释了跳过权限提示的参数与 bypassPermissions 模式之间的对应关系，还讨论了仍受限制的操作和替代模式。但现有信息没有列出这些限制，也没有说明替代模式各自适合哪些任务。
作者建议，只在受限环境中使用这类模式，并以非 root 用户运行。
理解这条建议，需要区分两层权限：工具是否向人请求确认，以及操作系统允许进程访问什么。取消前者，不会自动建立后者。Docker 可以提供进程和文件系统隔离，但容器挂载的目录、传入的凭据与开放的网络，仍会影响任务能够触及的范围。
免确认不等于隔离。
我的判断
对于无人值守编码任务，关键问题不是能否省掉点击确认，而是任务出错后能改到哪里。如果容器仍能写入重要宿主机目录，或持有高权限凭据，仅仅使用一次性容器，并不足以划清影响范围。
作者的测试有明确版本边界。24 次测试能覆盖哪些行为，要看测试用例，不能仅凭次数认定安全，也不能直接套用到其他版本。
目前最缺的是三类信息：哪些操作仍会被拦截、替代模式保留哪些确认，以及测试容器具体开放了哪些资源。在这些细节明确前，这份摘要能支持的是隔离方向，尚不能充当生产环境的权限配置依据。