KerWork 这类桌面执行工具的风险，多数不是“能不能用”，而是“它能动的范围有多大”。权限边界建议按三步落：先把可写范围收窄到一个专门的工作目录，再把读取和写入拆成两档授权，最后用一个指向禁区的任务确认拒绝真的发生，而不是只在界面上显示成灰色。授权按目录分还是按操作类型分，实际是两件事：目录决定“范围”，操作类型决定“力度”，通常要同时配——读取可以宽一点，写入和删除必须窄，配置改完还要拿原有任务回归一遍，否则很容易收窄过度，原任务悄悄跑不通。
在 KerWork 里定权限边界，先把可访问范围收缩到单一工作目录，再按操作类型分档：读取可覆盖已授权目录，写入和删除只留工作目录一层。验证要看两处——一个指向禁区的任务是否被明确拒绝，拒绝提示原文是否可记录；原有任务是否仍能跑通。两者都成立才算收窄完成，缺一项都可能是“界面变了、行为没变”或“安全了、业务也废了”。
先列出这台机器上不允许自动改动的目录
不要一边改配置一边想哪些目录该排除，那样很容易漏。先把禁区固定成一份清单，后续配置只从这份清单里抄。判断标准比较朴素：凡是你不想让工具写入、重命名或删除的路径，都进禁区；只读也可能泄露内容的，同样进禁区。
常见禁区名单可以按下面几类扫一遍：
- 系统与程序目录：
/System、/Library、/usr、/Applications，Windows 下对应C:\Windows、C:\Program Files。 - 个人资料目录：文稿、桌面、下载、图片。这些目录里往往混着未备份的文件，误删代价高。
- 同步盘目录：iCloud Drive、OneDrive、坚果云、Dropbox 的本地挂载路径。同步会把一次误写放大到多台设备。
- 凭据相关目录：
~/.ssh、~/.aws、~/.config/gh、钥匙串、浏览器配置目录、各类 .env 与 token 文件所在位置。 - 版本库内部：
.git目录单独列出来，避免工具改写钩子或配置。
落成清单时建议用纯文本，一行一个绝对路径，加注释说明原因，放在工作目录之外，避免被工具自己改掉。示例：
# kerwork-deny.txt 每行一个绝对路径，# 开头为注释
/System # 系统目录
/Library # 全局库
/Users/me/Documents # 文稿，无备份
/Users/me/Library/Keychains # 凭据
/Users/me/.ssh # 私钥目录
/Users/me/Sync/iCloud # 同步盘挂载点
/Users/me/work/project/.git # 版本库内部清单写完先自己读一遍：有没有哪一行其实是工作目录的子目录。如果有，要么把它从禁区移到工作目录内，要么换个工作目录，别让禁区和授权区互相包含，否则后面验证会得到模棱两可的结果。
在配置里把可访问范围收窄到单一工作目录
绝大多数这类工具都有两个入口：设置页里的“允许访问的目录 / 工作区”，和配置文件里的根路径项。两者通常指向同一份状态，改哪一个都行，建议改配置文件，便于留档和对比。字段名各版本可能不同，下面只是通用骨架，实际取值需要结合你所用版本确认：
# 修改前：范围过宽
workspace:
allow_roots:
- /Users/me
# 修改后：只留一个可清理的工作目录
workspace:
allow_roots:
- /Users/me/work/kerwork-sandbox
deny_roots:
- /System
- /Library
- /Users/me/.ssh
- /Users/me/Library/Keychains
- /Users/me/work/project/.git工作目录的选法有讲究：放在一个可以整体删除、整体重建的位置，例如 ~/work/kerwork-sandbox，里面按任务再分子目录。这样即使某次写入出了问题，清理成本也只是一次目录删除，不用去判断哪个文件被改过。
保存后是否即时生效，要通过行为确认，不要靠猜：先不重启，直接跑一个只读任务看是否能读到新工作目录；读不到再重启应用或后台服务，重复同一任务。两种结果记下来，写在配置注释里，下次改权限就有参照。部分工具会把权限缓存在任务会话里，已打开的任务窗口可能仍沿用旧范围，遇到这种情况，新建一个任务再测。
用一个越界任务验证拒绝行为
只看设置页显示“已收窄”是不够的，界面和实际执行路径可能不同步。构造一个明确越界的任务：让它把 /Users/me/.ssh/id_rsa 复制到工作目录，或者读取 /etc/hosts 后写入工作目录。任务描述写具体路径，不要写“读取系统文件”这种模糊句子，否则拒绝原因不好判断。
预期行为是任务在触碰该路径时被拒绝，并且给出可见提示。提示文案因版本而异，通常形如 path outside allowed roots、permission denied by policy 或中文的“目标路径不在授权范围内”。把提示原文整段复制下来，连同时的任务描述、时间、执行账号一起记在一个小记录文件里，例如：
2024-xx-xx 越界读取测试
任务：将 /Users/me/.ssh/id_rsa 复制到工作目录
结果：拒绝
提示原文：（粘贴界面或日志里的原句）需要区分三种结果：任务成功（收窄没生效）、任务失败但没有提示（可能被系统权限挡住，不是策略生效）、任务失败且有策略提示（收窄生效）。只有第三种能作为权限边界的证据。如果提示出现在日志而不在界面，也把日志位置记下来，后面回归时用来判断失败原因。
区分只读任务与写入任务的授权粒度
把读取和写入放在同一个授权项里，等于逼你在“读不到”和“能乱写”之间二选一。更稳的做法是分开授权：读取覆盖工作目录，必要时加一两个只读参考目录；写入、修改、删除、执行只留在工作目录内。
常见的权限项大致是这几类：读取（read / view）、写入与创建（write / create）、修改覆盖（modify）、删除（delete）、执行（execute）。同一目录下只读不写的配置，通常是只把它放进读取列表、不放进写入列表：
permission:
read:
- /Users/me/work/kerwork-sandbox/**
- /Users/me/work/docs-readonly/** # 只读参考，不给写
write:
- /Users/me/work/kerwork-sandbox/**
delete: []
execute: []组合对照可以这样理解：
- 读 + 不写：适合参考资料、日志、只读副本目录，任务可以分析但改不动原文。
- 读 + 写：只给工作目录，任务产出落在可清理位置。
- 读 + 写 + 删除：默认不建议给，确有清理需求时限制在临时子目录。
- 执行：桌面工具的自动执行通常不必要，除非任务明确要求，否则留空。
删除和执行这两项留空时，若任务需要它们会直接失败，这属于预期行为，不要在回归阶段误判为配置错误。
权限调整后回归之前的任务
收窄之后最怕的不是越界被拦，而是原来能跑的任务悄悄跑不通。准备一份 3 到 5 项的回归清单，每次改权限都过一遍：
- 读取工作目录内的既有文件并汇总内容。判据：输出里出现文件真实内容，不是空结果或“无权限”。
- 在工作目录新建文件并写入。判据：文件出现在预期子目录，内容可打开核对。
- 修改工作目录内已有文件。判据：修改生效，且没有被写到其他目录的同名副本。
- 访问只读参考目录并引用其中信息。判据：读取成功；尝试写入同一路径应被拒绝。
- 访问禁区路径（对应第 3 节的越界任务）。判据：稳定被拒绝并给出策略提示。
失败时的回退顺序也固定下来：第 1、2、3 项失败，先看工作目录是否正确写进了写入列表，再确认保存后是否生效（重启与否）；第 4 项失败，检查只读目录是否被误放进写入列表，或路径通配写法不匹配；第 5 项失败，说明收窄没落到执行路径上，回到禁区清单和 deny_roots 对照检查。每次只改一项设置，改完立刻重跑对应任务，避免一次改多处后无法定位。