dsh-auto-mode

用 DeepSeek Harness 做真实项目时，最磨人的往往不是代码本身，而是权限模式的两难：Restricted 模式每走几步就打断一次，Full access 又等于完全取消审批，让人心里没底。dsh-auto-mode 想补上的正是这块空白——它不另造沙箱，而是继续使用官方 workspace-write 文件沙箱，只在普通开发动作之外增加一层语义风险审查。日常的构建、测试、依赖安装和项目内操作照常顺畅运行，只有跨越工作区边界的操作才会被分类处理：明确安全的自动放行，真正模糊的询问一次，涉及关键路径破坏或策略绕过的直接拒绝。

这个插件的核心是一套基于当前会话模型的分类机制。它不会自己拥有授权能力，只能从人类用户的直接消息里识别许可；仓库文本、工具输出、Assistant 文本、Skills 或子代理都不能越权。删除策略比普通写入更严格：本会话刚创建的产物可以自动清理，但已存在的文件必须先有用户精确指名才会分类，而根目录、Home、DSH_HOME 等危险路径无条件拒绝。对于 Shell 命令，Auto 不再试图用白名单证明每一条语法安全，未知命令直接在官方沙箱里运行，由操作系统拦住工作区外的写入；只有藏在变量或 glob 后面的可执行名会在后台被拦下，让 Agent 改用可见命令重试。

如果你是希望 Agent 能连续干活、又不想把审批完全关掉的开发者——尤其是需要处理构建、测试、脚手架生成和本地 Git 提交的日常项目工作——这个模式会很有吸引力。子代理、Workflow 调用和 Ralph 派生进程都会继承 Auto 的边界，且不能自行升级到 Full access。对于需要写工作区外一次性窄目标的场景，任务意图足够明确时也能后台授予单次许可，但覆盖或删除已有数据仍必须由用户直接、精确地说明。

需要强调的是，Auto 不是让 Full access 变安全的补丁，而是尽量让你不需要 Full access：绝大多数操作留在沙箱内，真正必要的那一点越界能力以最小范围借出一次。如果你能接受“沙箱管写入位置、分类管语义风险、用户管真正模糊的决定”这种分工，dsh-auto-mode 值得在下一个 Harness 项目里试试。