diff --git a/docs/reference/code-queue-supervision.md b/docs/reference/code-queue-supervision.md
index 49aa5854..f862c2c4 100644
--- a/docs/reference/code-queue-supervision.md
+++ b/docs/reference/code-queue-supervision.md
@@ -55,6 +55,8 @@ GitHub issue 是长期需求、缺陷、阻塞和决策的 source of record。
 
 issue 内容必须自包含，至少写清楚背景、外部收益、当前观察、需求范围、非目标、验收标准和关联任务。不要只贴聊天摘要或只写“见某任务”；Code Queue worker 可能看不到 issue，也可能无法访问完整历史，因此 issue 是人类和指挥官恢复全局态势的记录，不是 worker prompt 的替代品。
 
+如果某个 worker 任务需要依赖 GitHub issue 内容，但 runner 的 issue 可达性尚未被单独验证，指挥官不能默认 worker 已能读取该 issue。此时 worker prompt 必须直接内嵌完整需求、约束和验收点，issue URL 只能作为辅助引用。若要把 issue 作为任务输入源，先单独做可达性探测，再决定是否把 issue 作为常规前置条件。
+
 如果 `gh issue create` 的 GraphQL 路径因为 token scope 或 repository metadata 查询失败，允许使用 GitHub REST API 创建 issue。CLI 或脚本应避免在日志中打印 token；失败原因应归类为 GitHub 凭证/CLI 兼容问题，而不是业务任务失败。
 
 PR 是审查型交付入口，不是所有 Code Queue 任务的默认出口。默认 master-only 交付仍按项目 Git 规则执行；当变更风险高、跨模块、需要人工审查、或任务目标明确要求 PR 交付时，worker 可以创建 PR。PR 型任务必须报告源分支、目标分支、PR URL、关联 issue、测试证据和未完成风险。禁止把 PR 当成隐藏分支仓库；PR 分支必须来自最新目标线，保持小而可审查，并在合并后确认目标分支远端 commit 可 fetch。
diff --git a/docs/report/202605/20260520_Commander.md b/docs/report/202605/20260520_Commander.md
index 6758410d..f88dc029 100644
--- a/docs/report/202605/20260520_Commander.md
+++ b/docs/report/202605/20260520_Commander.md
@@ -20,6 +20,7 @@
 
 - 运行中任务需要“引导优先于打断”。2026-05-20 现场发现 runtime 已有 `/api/tasks/:id/steer` 能力，但 `bun scripts/cli.ts codex --help` 未暴露正式 `codex steer`；指挥官临时通过 `microservice proxy code-queue /api/tasks/<id>/steer --method POST` 给 #16 任务注入纠偏信息，避免把 runner 内 CLI 视角误判为 D601 整体离线。长期建议：实现正式 `bun scripts/cli.ts codex steer <taskId>`，见 GitHub issue #17。
 - GitHub issue 是跨轮次需求、阻塞和决策的长期记录；PR 是审查型交付入口，不是默认出口。相关长期规则已写入 `docs/reference/code-queue-supervision.md`，后续指挥不在本报告重复展开。
+- Code Agent 沙箱现在按“独立服务先行、Code Queue 后接契约”的方式推进。2026-05-20 已创建执行 issue #18，并把它排入 `provider` 队列；该任务只负责把独立沙箱骨架、adapter、模式和 credential 边界先落出来，不把 Code Queue 设为前置依赖。
 
 ## 快照 2026-05-20 04:16 UTC
 
@@ -216,6 +217,31 @@ worker prompt 必须包含目标分支，final response 必须报告：
 - judge 对基础设施恢复任务应区分“source-of-truth 恢复验收”和“live runtime 上线验收”。如果任务 prompt 原本只要求恢复远端 commit，judge 可以提示后续上线任务，但不应无条件把它 retry 成部署任务；除非 prompt 明确要求 live service 必须消费该变更。
 - 对 Code Queue 自身的 live 重启/重建必须在 final response 中报告影响范围、是否触发 restart-recovery、恢复后哪些正在运行任务仍保持 heartbeat 新鲜。
 
+## 更新 2026-05-20 05:43 UTC
+
+本轮有两件实质进展：
+
+1. `codex_1779247828759_1`（#12 frontend）已完成审阅并用 `bun scripts/cli.ts codex read codex_1779247828759_1` 标记已读。该任务的 final response 和 judge 一致：DEV targeted E2E 3/3 通过，前端已部署到 prod，`/health`、公网 `/app/code-queue/` 和 live `codex tasks --limit 1` 都有可复核证据。最终 commit 是 `941fa853904a9701cd1a8de2e88ff4e4e035f8e3`，这条线可以从“完成未读”转入已读审阅记录，不再占用监督注意力。
+2. 已创建并派发执行 issue #18：`落地独立 Code Agent Sandbox 微服务（基于 #4 评审结论）`。随后把它排入 `provider` 队列，任务 id 为 `codex_1779255781990_1`。该任务的显式边界是“沙箱先独立、Code Queue 后接契约”，不要求 Code Queue 在本轮依赖沙箱。
+
+当前监督态势：
+
+- 运行中：3
+  - `codex_1779247780398_1`（#12 backend/API）
+  - `codex_1779248052767_1`（#13 frontend stats）
+  - `codex_1779250940463_1`（#16 恢复）
+- 排队中：5
+  - `codex_1779248021103_1`（#13 backend/API stats）
+  - `codex_1779248189933_1`（#14 split-brain UI）
+  - `codex_1779248492207_1`（#15 PR 支持）
+  - `codex_1779254388587_1`（#17 codex steer 正式化）
+  - `codex_1779255781990_1`（#18 独立 Code Agent Sandbox 微服务）
+
+长期化建议：
+
+- 沙箱执行线和 Code Queue 产品线要保持契约解耦。沙箱先独立成服务，先把 adapter、运行模式、凭证/Token 切换和恢复语义做稳，再由后续任务把 Code Queue 消费端接上。
+- 对于这类“独立基础设施执行 issue”，队列里应优先放在 provider / infra 这类写面较低的 lane，避免和 frontend / code-queue 的高冲突任务互相覆盖。
+
 ## 更新 2026-05-20 04:44 UTC
 
 指挥官仓库已快进到：
@@ -277,3 +303,19 @@ worker prompt 必须包含目标分支，final response 必须报告：
 
 - 继续等待，不打断。#12 两条线都有明确下一步，#16 也已经把阻塞点收敛到 provider bridge。
 - 如果 #16 下轮仍停留在 provider bridge offline，应把“D601 provider-gateway SSH 维护桥恢复/Code Queue 执行面本地重启路径”拆成单独 infra task，而不是让 #16 恢复任务无限等待。
+
+## 更新 2026-05-20 06:11 UTC
+
+这轮专门核实了“runner 是否能读写 GitHub issue”。结论已经明确：
+
+- runner 侧 `gh issue view 18 ...` 首次失败于 `gh: command not found`；
+- 失败不是权限拒绝，而是工具链不可用；
+- 于是不能把 issue 可见性当作默认前提，也不能让后续派单只贴 issue 链接。
+
+为避免以后重复踩这个坑，已创建 GitHub issue #19，专门记录：
+
+- runner 侧 GH issue 可达性前置条件缺失；
+- 后续派单 prompt 必须内嵌完整需求；
+- 需要显式验证 gh 工具、认证和可见性边界。
+
+同时也补了长期监督规范：当 worker 任务依赖 issue 内容而 runner 还没验证可达性时，prompt 必须自包含，issue 只能当辅助引用。后续若要把 issue 当成常规输入源，必须先单独做可达性探测。