|
|
7fe279676a
|
fix(pi-bridge)!: --rw 的 cwd 与 worker 实际用的 cwd 收成**一处决定**（pi 探针实测的第三例）
pi 2026-09-15 报、我用探针复核**成立**，而且它把 `99e6560` 的代价也一起说清了。
**分叉在哪**：cwd 有**两个来源**，而会话键 `keyOf(data) = data.session_id` **只看 session_id**：
```
父进程（算 --rw） cwd = resolveWorkspaceCwd(to_workspace, …) ← 来源：**这封信的地址**
子进程（真去干活） cwd = job.session.cwd || resolveWorkspaceCwd(…) ← 来源：**会话上次实际用的 cwd**
```
于是同一 session_id 下地址换个形状（`pi@/some/dir` → `pi@.<会话>`），父进程按**新地址**
算 rw，worker 却**复用会话、落在旧 cwd**。实测（真函数，`exists` 注入）：
```
父进程算的 cwd = /root/.pi/mail-sessions/sess-x
worker 实际会用 = /home/program/agentmail （= 该会话的 state.cwd）
rw 含 worker 实际 cwd? = false ⇒ 界内 EACCES
```
不是假想：本线程那条会话自上线起每次启动的 rw 都是 `/home/program/agentmail`，
那就是它的 `state.cwd` —— 此时来一封 `pi@.<会话>`（不带 path）的信就会踩到。
**★ `99e6560` 在这个组合上把失败方式变坏了**（这条必须记下来，我原先只报了它的好处）：
· 之前：兜底目录不存在 ⇒ 不套沙箱 ⇒ `ask`（有人应答时**写得进去**）
· 之后：目录被建出来（那次修复的效果）⇒ **套上沙箱，而 rw 是地址算的那个**
⇒ worker 在会话自己的 cwd 里写 ⇒ **EACCES，且没有"问一次"这条路**（内核拒的）
我用 `ensureCwd` 前/后各跑一次验证了这条因果，实测 `(b) 建了兜底目录: sandboxed = true,
rw 含 worker 实际 cwd? = false` —— 与 pi 报的 `sandboxed=true` 一字不差（他给了那个值，
我最初复现成 false，差别就在"兜底目录建没建"，属于应用 `99e6560` 前后）。
⇒ **两处修复必须一起部署**，否则中间态是"界内也写不了"（比原先多问一次更糟）。
现在两次提交都在仓库、`drift` 报 5 处待部署，会一起上线。
**修法**：新增 `src/turn-cwd.mjs` 的纯函数 `resolveTurnCwd()` —— 输入全部来自**父进程也拿得到的
public 状态**（`sessionReused` / `storedCwd` / `toWorkspace` / `sessionKey` / 注入的解析函数），
父子两侧都从它取值；父进程再把决定**注入 job**（`session.resolvedCwd`），worker **消费**它、
不再自己推导。于是"三来源变一来源"落了第一步。
**判据（pi 要的那条等式）**：
· ★**等式**：用真 `sandboxWritePaths` 算 rw，断言"**`--rw` 里的 cwd === worker 会用的 cwd**"；
并附**反面对照**：按地址算出来的 rw **不含** `state.cwd`（= 修复前的错位状态）。
· 复用/非复用/`storedCwd` 为空三种输入各一条。
· 结构：pool 必须把决定交给 `workerLaunch` **并**注入 job；worker 取 cwd 的**每一处表达式**
都必须先看 `resolvedCwd`。
★ **两处我自己的判据缺陷，都是变异测出来的，都记在测试文件里**：
1. 上一轮我在 `sandbox-launch.test.mjs` 写的 `assert.match(src, /resolveWorkspaceCwd\(/)`
**本来就不该红也不该绿** —— 它护的是**写法**（池子直接调那个函数），而引入 `resolveTurnCwd`
后池子改成"当参数传进去"（更对），它才红。**红得对**：它当初断言的是实现细节，
不是它想要的性质。已改为断言性质（解析函数必须来自共用模块、且被显式传给纯函数）。
顺带说明：它此前一直是**假绿**还是**真绿**我没法回测，但**它在引入纯函数后才红**说明它
确实绑定了写法 —— 这正是"判据的适用范围没写出来"那一类。
2. 新版 worker 侧结构判据**第一版不具区分力**：只断言"文件里出现 `resolvedCwd`"，
把消费那一支删掉、退回 `job.session.cwd`，正则**仍然匹配**（别处还留着它）⇒ 变异后依旧全绿。
已改为断言**优先级**（取 cwd 的表达式必须含 `resolvedCwd`）。
★ 变异实测：修好后重做同一变异 ⇒ 判据**变红**；两次变异均 `cp` 恢复 + `cmp` 校验。
**残余（未修，已进 DEBTS）**：**接管会话**那条路 worker 用会话文件 header 里的 `info.cwd`，
父进程读不到 ⇒ 首回合仍可能错位。父进程要拿它得用 `session-scan.mjs`，而 `readHeader` 未导出、
整表 `scan()` 在父进程里代价大（worker 里实测 1431ms / 240MB）。
彻底方向即 pi 说的：把"这次用哪个 cwd"完全收成父进程一处决定，worker 只消费。现在做不做等定。
验证：pi 桥 **502/502**；另三个桥 fail 0；`check-shared-libs` exit 0；`install.sh --check` exit 0。
|
2026-09-15 06:47:10 +08:00 |
|
|
|
99e6560122
|
fix(pi-bridge): 首回合也要套沙箱 —— pool 在算 launch 前先把兜底目录建出来（pi 报的同形缺口）
pi 2026-09-15 报的缺口，我先逐环核了再改（**成立**）：
```
pool.mjs:190 cwd = resolveWorkspaceCwd(to_workspace, piMailFallback(session_id)).cwd
↓ 地址不带 path（`pi@.<会话>`）⇒ cwd = ~/.pi/mail-sessions/<key>
↓ **这个目录第一次不存在**
sandbox.js:168 if (!cwd || !exists(cwd)) return direct("拿不到会话工作区") ← 不套沙箱
worker.mjs:388 ensureCwd(cwd, grouped) ← 建目录的人**在决定之后**才跑
```
⇒ 无 path 的新会话**首回合不套沙箱** ⇒ 父进程不打 `AGENTMAIL_PI_SANDBOXED`
⇒ worker 的 `sandboxActive()` 为假 ⇒ `guardDecision(workspace, sandboxed=false)` = **`ask`**
⇒ **"界内不问"这条保证对无 path 新会话的首回合不成立**。
**端到端实测（不是推理）**，用真函数跑了一遍无 path 新会话：
```
解析结果 cwd = /root/.pi/mail-sessions/brand-new-key-probe | grouped = false
修复前（目录不存在）: sandboxed = false | 拿不到会话工作区（…）—— 不猜 → guardDecision = ask
修复后（目录已建） : sandboxed = true
rw 含兜底目录 = true ; rw = […/brand-new-key-probe, /tmp, /root/.pi/agent] → guardDecision = allow
```
**修法**（pi 给的最小修法）：pool 在 `workerLaunch` 之前调 `ensureCwd(cwd, grouped)`。
`ensureCwd` 只在 `!grouped` 时建，所以 **N-2「笔误不落真目录」不受影响**：
path 位给了但不存在 ⇒ `resolveWorkspaceCwd` 返回**兜底**+grouped=false ⇒ 建的是兜底目录，
笔误路径永远不会被创建。（这点我单独核过，因为"顺手建目录"最容易在这里越界。）
同时把 `resolveWorkspaceCwd` 的调用收成一次（原先在参数里内联算 cwd），
保证"用来判 exists 的 cwd"与"拿去当 --rw 的 cwd"是**同一个值**。
**判据（行为 + 结构，含顺序断言）**：
· 行为：兜底目录不存在时 `sandboxed=false` 且理由是"拿不到会话工作区"
—— 这条**真规则是对的**，不能改成"无条件套"（`am-sandbox` 对不存在的 `--rw` fail closed，126）；
· 结构：`src/pool.mjs` 里 `ensureCwd(` 必须出现在 `workerLaunch(` **之前**
—— 光判"调没调"不够：顺序错了等于没补（这正是当初 worker 建目录的位置问题）。
★ 已先验区分力：移除 `ensureCwd` 调用 ⇒ 新判据**变红**（12/1），`cp` 恢复后 `cmp` 校验一致。
**为什么原判据护不住**：`sandbox-launch.test.mjs` 的 `fsRealShape()` 里 cwd 总是存在的，
而生产里这个 cwd **恰恰是 worker 自己建的** ——
与前面 `agentDir` 那次是同一个形状（夹具把生产形状简化掉的那一角，正是出问题的那一角），
只是换了另一角。这是同一条教训的第二个实例，值得并进 docs。
验证：pi 桥 **497/497**（+1）；另三个桥 fail 0；`check-shared-libs.sh` exit 0；
`install.sh --check` exit 0；`drift` 报 4 处待部署（`src/paths.mjs` 新增 + 三个文件内容不同），
与本次改动一致 —— 这条红正是"待部署"的可操作信号。
|
2026-09-15 06:33:49 +08:00 |
|
|
|
7f03ee7ca2
|
fix(pi-bridge)!: 沙箱 rw 漏了 agentDir 本身 —— pi 侧的 Agent 整个不工作（凭据存储的锁文件写在它直下）
**症状（实测，2026-09-15）**：pi 处理不了任何一条消息 —— 回给 dsh 的是一封
「处理失败」通知：
auth: Credential store read failed for llmsproxy:
EACCES: permission denied, mkdir '/root/.pi/agent/auth.json.lock'
已尝试 1 个：llmsproxy/AUTO
即**不是某次工具调用失败，而是这个 agent 完全不工作** —— 而它正是这条线上唯一的对端。
**根因**：`sandboxWritePaths` 把 `<agentDir>/sessions` 放进了 `--rw`，
**却没放 `<agentDir>` 本身**：
pushDir(join(agentDir, 'sessions')); // 少了 pushDir(agentDir)
而 pi 的凭据存储在 **`<agentDir>` 直下**建锁文件 `auth.json.lock`
⇒ Landlock 拒绝在 `agentDir` 里新建条目 ⇒ 读凭据这条路直接失败。
**因果链已在真二进制上闭合**（`/opt/agentmail/bin/am-sandbox`，非推理）：
# 只给 sub、不给父（= 修复前的形状）
--rw /tmp/ll2/allowed/sub → echo > /tmp/ll2/allowed/newfile
/bin/sh: cannot create …: Permission denied ← 就是 pi 的那个 EACCES
# 给父目录（= 修复后的形状）
--rw /tmp/ll2/allowed → 退出码 0，文件建出来
也确认了 `am-sandbox` 的语义确实是「**及其子树**」（`--rw` 给出的目录连同子树可写），
所以补上父目录这一条就够，不需要为锁文件单独加 `--rw-file`。
**为什么以前的判据护不住这一处 —— 夹具形状把出问题的那一角简化掉了**：
`sandbox-launch.test.mjs` 每个用例手写
`fsWith([..., `${HOME}/.pi/agent/sessions`, ...])`，**只列 sessions、不列 agentDir**，
于是"agentDir 在不在 rw 里"在这套测试里**永远测不出来**。
已加一个贴着生产形状的夹具 `fsRealShape()`（agentDir 与 sessions **都在**），
并把两个 workerLaunch 用例换成它。
**判据（两条，含反面对照）**：
· `agentDir` 本身必须在 `--rw` 里，且 `sessions` 也仍在（两个写点，不是替代关系）；
· 反面对照：`agentDir` **不存在**时不得硬塞进 rw ——
`am-sandbox` 对不存在的 `--rw` 路径 fail closed（退出码 126），
所以"加 agentDir"不能变成"无条件加"。
★ 已按既定纪律先验区分力：临时移除 `pushDir(agentDir)` ⇒ 新用例**变红**（11/1），
`cp` 恢复后 `cmp` 校验一致。
**旁注（写点清单的教训）**：原来的注释只按"我们已知的写点"列（会话工作区、临时目录、
/dev/null、sessions、配置目录），而**凭据存储在它自己的目录里加锁**是另一个写点，
且它在**读凭据**这条路上 —— 所以漏了它的症状不是"某个工具不能用"，而是"agent 不工作"。
写点清单要按**真实进程的行为**列，不能只按已知的那几处列。
验证：pi 桥 491/491（新增 2 条）；sandbox-launch 12/12；`go test ./cmd/am-sandbox/` ok。
|
2026-09-15 00:13:13 +08:00 |
|
|
|
9fa509844a
|
feat(pi-bridge): 有沙箱时 workspace 档不再逐条问人 —— 界内不问、界外内核拒
沙箱上线后，"工作区档"的语义第一次可以按档位表兑现：**边界是内核在守**，再问一遍
只是让人点一次"同意"，点完该失败的还是失败（人点了也挡不住内核）。所以闸门改成
**按档位 × 有没有沙箱** 决策，纯函数收在 `lib/sandbox.js`：
| 档位 | 沙箱 | 决定 |
|---|---|---|
| full | 任意 | allow（发件人已声明全权） |
| plan | 任意 | block（本档只许看；沙箱是第二层） |
| workspace | **在** | **allow** ← 这一步改的（界内不问、界外 EACCES） |
| workspace | 不在 | ask（回退到原来那唯一一层） |
没有沙箱时**继续问** —— 这条是"不会更松"的保证：沙箱缺失/未装/被关掉时行为与改前
逐字一致。
## 标记不等于事实：worker 自证
`AGENTMAIL_PI_SANDBOXED=1` 只是父进程的**声明**。判断错会让闸门既不问也不拦
（最坏的一类），所以 worker 现场自证一次：往界外写一个金丝雀（`/.agentmail-sandbox-canary-<pid>`，
根目录永远不在 rw 里）—— 写得进去 ⇒ 判为"没有沙箱"，**退回逐条问人**（方向取严）；
被拒（EACCES/EROFS/EPERM）⇒ 在边界内。结果缓存在进程级。
## 顺带把 plan 档变成真的只读
plan 档的 rw 清单**不含会话工作区**（只有临时目录/pi 会话登记/桥配置/`/dev/null`）：
"一个字都不许写"从"钩子拒绝 + 提示词"{升级为内核第二层。
## 判据
- `sandbox-launch.test.mjs` 10 条（原 6 + 新 4）：决策矩阵四档 × 有无沙箱、
自证两侧（被拒=在边界内；能写=必须判"没沙箱"）、plan 档 rw 不含工作区、
"pool 设标记 + worker 自证 + 走 guardDecision"三处接线在。
- 变异：把 workspace+sandboxed 改回 'ask' ⇒ 那条断言红。
- pi 桥全套 489 项通过。
- ★ 又被自己撞一次同类坑并当场红：新变量起名 `decision`，与同一个函数里后面那个
`const decision = await new Promise(...)` 撞名 ⇒ SyntaxError。上一轮的 `spawn`
撞名也是这一族（局部名与既有作用域重名），两次都是**语法检查/测试**立刻抓到。
## 文档
`docs/PLAN.md` §7.11 的 L5 矩阵与"向更严取整"那条纪律、`docs/API.md` 的档位表
都改成新语义（有沙箱=内核拒、无沙箱=逐条问），并写明 pi 的沙箱为什么必须由宿主提供。
|
2026-09-14 23:50:35 +08:00 |
|
|
|
64f002cf66
|
feat(pi-bridge): worker 按档位套沙箱 —— plan/workspace 进 Landlock 边界，full 档不进
上一步（1f48c5c）做出并验了边界工具；这一步把它接到 worker 的启动路径上，
于是「工作区档 = 本目录内可动」第一次由**内核**保证。
## 规矩
- `plan` / `workspace` 档 → `am-sandbox --rw <会话工作区> … -- node worker.mjs`
- `full` 档 → **不套**（发件人已声明全权，与档位表一致）
- 拿不到会话工作区 → **不套**，并把理由打进日志（猜一个 `--rw` 会让"界内也写不了"）
- 启动方式从 `fork` 换成 `spawn`（fork 只会 exec node，套不进中间那层），
`stdio` 里带 `'ipc'` 时 node 同样设 `NODE_CHANNEL_FD`，而沙箱是 exec 透传
⇒ worker 的 `process.send` 照常可用
## rw 清单是**实测得出**的，不是想当然
`lib/sandbox.js` 里那几条（会话工作区 / `os.tmpdir()` / `<agentDir>/sessions` /
`AGENTMAIL_CONFIG_DIR` / `--rw-file /dev/null`）每条都对应一个真实的失败模式：
少了 `/dev/null`，`cmd 2>/dev/null` 一律 Permission denied（实测撞到）；少了
`<agentDir>/sessions`，回合结束保存会话就失败。真机验证：一个**真实的 pi agent**
跑在边界里，界内写成功、`/opt` 被拒（Permission denied），并如实汇报两者。
## 两处必须收成一处的东西
- 会话工作区由**父进程**用与 worker 同一个函数解析（`resolveWorkspaceCwd`）——
父进程猜一个目录当 rw、worker 落在另一个，症状是最难查的那一类
- `piMailFallback` 从 worker 挪进 `lib/workspace.js`：父进程要用同一个兜底值
## 判据与踩到的坑
- `sandbox-launch.test.mjs` 6 条行为断言（套/不套、rw 里有 cwd 与 /dev/null、
`--` 之后是 node+worker、拿不到 cwd 时的理由、env 开关三态、rw 去重与只收存在的路径）。
变异"永不套沙箱" ⇒ 恰好那几条红。
- ★ 池测试原先会**随这台机器装没装 am-sandbox 而变** —— 那正是假绿的来源。
给 `createWorkerPool` 加了 `env` 注入点，测试显式 `AGENTMAIL_PI_SANDBOX=off`。
- ★ 给 import 起名 `spawn` 撞上本文件已有的 `function spawn(job)` ⇒ 自己调自己
（`RangeError: Maximum call stack size exceeded`，池测试当场红）。改名 `spawnProcess`。
- pi 桥全套 485 项通过。
|
2026-09-14 23:43:06 +08:00 |
|
