OpenWorker 这类本地代理在首次启动时,通常会把「当前用户能访问的位置」当作默认工作范围,而不是你正在编辑的那个项目目录。装好之后先别急着跑任务,第一件要做的事是打开设置页或首次启动的权限提示,把默认的读、写范围逐条抄下来,再把可写范围收窄到一个项目文件夹,最后用一个只读任务验证边界确实会被拒绝。判断标准很简单:越界请求返回的是明确的拒绝或报错,而不是悄悄成功。
刚装好的 OpenWorker 通常沿用户级权限工作,默认能触到的位置比项目目录大。处理顺序建议是:先记录首次启动权限提示里的每一项读/写范围,再把工作目录改成一个具体项目路径并确认重启或重新加载后生效,然后用读取工作目录之外文件的任务验证拦截,最后在放开写权限前先做目录副本或用只读挂载兜底。判断边界是否生效,以日志里出现拒绝记录、而不是任务「似乎没出事」为准;具体字段名和日志位置需结合你安装的版本确认。
首次启动时它到底请求了哪些目录权限
不要凭印象假设它只能碰当前项目。启动后先看首次授权弹窗或设置页的权限清单,把每一项按「只读」和「可写」分开记,再决定哪些可以留、哪些必须收。下面是记录表的字段,照着填一遍比反复猜测有用;至于条目名称,以你界面上实际出现的文字为准,这里只给结构。
| 权限项(按界面抄录) | 范围 | 读/写 | 任务是否必需 | 处置 |
|---|---|---|---|---|
| 读取用户主目录 | 整个 home | 只读 | 否 | 收窄到项目目录 |
| 写入工作区 | 启动时所在路径 | 可写 | 视任务 | 先改成项目子目录 |
| 执行本地命令 | 继承当前 shell | 可写(间接) | 否 | 先关,验证阶段再开 |
| 读取系统配置目录 | /etc 等 | 只读 | 否 | 保留只读即可 |
填表时重点看两类:一是范围写成「home」「/」这种顶层路径的条目,二是同时具备读和写、范围又很宽的条目。只要某个条目对当前任务不是必需,就先关掉或收窄,后面要放开随时可以再加。
把可访问范围收窄到一个项目文件夹
首选做法是在设置页里把工作目录改成项目的绝对路径,其次才是改配置文件。设置页通常有「工作目录」「允许读取的额外路径」「是否允许访问工作目录之外」这几项,逐项填绝对路径,不要用 ~ 或相对路径,避免解析差异。如果只有配置文件,可以参考下面的结构,字段名以你安装版本的配置为准,属于示意骨架:
{
"workspace": {
"roots": ["/home/you/projects/demo-app"],
"read_only_roots": ["/home/you/projects/shared-docs"],
"deny_outside_workspace": true,
"allow_shell": false
}
}
改完是否要重启,取决于它加载配置的时机:写文件的方式一般需要完全退出进程再启动,设置页里改的通常重新加载会话或新建会话即可。稳妥的判断方式是改完后看两处——设置页里回显的路径是否已经变了,以及启动日志里是否有打印生效的允许路径。两处都印证之后再跑任务,否则可能仍在用旧范围。
用一次只读任务验证边界有没有生效
验证不要用写操作,先让它读一个明确在工作目录之外的文件,比如 /home/you/Documents/note.txt,或者工作目录同级另一个项目的 README。指令写具体一些:
请读取 /home/you/Documents/note.txt 并原样返回前 20 行,不要做其他操作。
看返回的是什么。正常的拦截形态通常是明确的拒绝文案,例如「路径不在允许的工作目录内」「访问被策略拒绝」这类表述,也可能直接抛错;不同版本措辞不同,以你界面上实际出现的文本为准。如果它顺利读出了内容,说明范围没收窄成功或配置没生效,先回到上一节确认路径和重启。把这次的拒绝提示原文记下来,后面排查日志时要用同一个关键字去对。
写操作前先留副本再放开权限
放开写权限之前,给项目目录留一份完整副本,不要只靠版本控制,因为未提交的改动和生成文件不一定在库里。备份命令可以在项目父目录执行:
tar -czf ~/backup/demo-app-$(date +%F-%H%M).tar.gz -C /home/you/projects demo-app
如果要让代理在写入阶段也安全,可以考虑不直接给它可写目录,而是把副本目录交给它写,或者在 Linux 上做一个只读挂载点指向原项目:
sudo mount `--bind` -o ro /home/you/projects/demo-app /mnt/demo-ro
这样即使它尝试写入,也会在文件系统层失败。写入失败时的反馈通常是页面上出现操作失败提示,日志里对应 EACCES 或 Read-only file system。看到这类反馈先别急着放宽权限,先确认是不是刚好证明了边界在起作用。
在日志里定位是哪一次调用越了界
日志一般在安装目录或用户配置目录下的 logs 子目录,设置页里通常也有「打开日志目录」的入口,需要结合你的安装方式确认位置。定位时看四类字段:时间戳、会话或任务标识、调用的工具名、以及被访问的路径和判定结果。把权限问题和模型行为问题分开的关键,就是看判定结果字段写的是允许还是拒绝。可以用下面的命令先粗筛:
grep -nE "denied|outside|allowed_roots|EACCES|blocked" ~/.openworker/logs/*.log | tail -n 50
配合上一节那次人为触发的越界读取,按时间戳找到那一条记录:如果拒绝记录出现在同一时间点,说明是策略层拦下的;如果日志里根本没有这条访问,或者判定为允许但结果异常,那更可能是任务描述或工具调用方式的问题,需要改提示词或收紧工具开关,而不是继续调目录配置。