feat(mesh): add programmatic agent launch boundary - #11224
Conversation
4f21280
into
codex/multi-agent-mesh-foundation
|
Thanks for the PR! First, where this actually stands: #11224 is already merged — by you, 35 seconds after it was opened — into the stacked branch Template looks good ✓ — every required heading is present and filled in, the Tested-on table is honest about what's still pending, and the Chinese section is a full translation rather than a summary. Problem: this is a Direction: coherent, and the split is the right call. Keeping the runtime seam in its own child PR is exactly what stops #11206 from becoming one unreviewable change spanning a 4,500-line shared hot path plus the entire mesh subsystem. The one direction-level question I'd want settled before #11206 reaches Size: all 10 files sit under Approach: the scope feels right. I sketched my own design before reading the diff — thread a narrow programmatic option through the existing invocation instead of duplicating spawn logic, intersect the definition's tools with the mesh ceiling rather than unioning them, persist a mesh marker in the meta sidecar and re-derive the boundary on cold resume — and this is essentially that design, which is a good sign rather than a reason to rubber-stamp it. Nothing drive-by, no formatting churn, no speculative configurability. One modelling question carries into the review: Risk: no elevated path signals — none of the changed files match the revert-correlated high-risk set. But review depth goes up anyway for a different reason: this commit has no CI signal whatsoever, and the launch-side half of the new security boundary is not covered by any test. Both are detailed in the review below. Moving on to code review. 🔍 中文说明感谢贡献！ 先说明当前状态：#11224 已经合并——由你在开启 35 秒后自行合并——目标是 stacked 分支 模板完整 ✓ ——所有必需小标题都存在且已填写，Tested-on 表格如实标注了仍待验证的项，中文部分是完整翻译而非摘要。 **问题：**这是 方向：思路连贯，拆分也是对的。把 runtime seam 单独放进子 PR，正是避免 #11206 变成一个同时横跨 4500 行共享热路径和整个 mesh 子系统、无法评审的巨型改动的关键。在 #11206 进入 **规模：**10 个文件全部位于 **方案：**范围合理。我在读 diff 之前先勾画了自己的设计——在现有 invocation 上穿一个很窄的 programmatic 选项，而不是复制一套 spawn 逻辑；对 definition 的工具做交集而非并集；在 meta sidecar 里持久化 mesh 标记，冷恢复时重新推导边界——而这个 PR 基本就是那套设计。这是个好迹象，但不构成直接放行的理由。没有夹带无关改动，没有格式化噪音，没有投机性的可配置项。有一个建模疑问带入评审： **风险：**无路径层面的升级信号——改动文件均未命中与 revert 相关的高风险路径集合。但审查深度仍然提高，原因是另一件事：这个 commit 完全没有任何 CI 信号，并且新安全边界的启动侧没有任何测试覆盖。两者都在下面的评审中详述。 进入代码审查 🔍 — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
Code reviewI went in expecting to find a hole in the capability boundary and mostly didn't — the design is careful, and several things that look risky on a first read turn out to be handled. Let me record what I cleared as well as what I didn't, because the cleared list is where a reviewer of #11206 would otherwise spend their time. Checked and cleared:
What I'd actually flag: 1. The launch-side half of the boundary has no test. This is the one I'd want addressed before #11206 merges. 2. No CI ran on this commit, so nothing above was machine-checked. Not a code defect, but it changes what the review is worth: I read this statically, and typecheck / lint / format / the four named test files have never executed against 3. 4. Question for the product decision, not the code: the ceiling bounds writes, not read scope. Launch and cold-resume flow, with the tested and untested halves markedsequenceDiagram
participant P1 as launchMeshAgent (launcher.ts)
participant P2 as deriveConfig mesh guard
participant P3 as launchProgrammaticBackgroundAgent
participant P4 as AgentToolInvocation.execute
participant P5 as createApprovalModeOverride
participant P6 as createAgentHeadless
participant P7 as BackgroundAgentResumeService
P1->>P1: loadSubagent then convertToRuntimeConfig
P1->>P1: buildMeshToolConfig, definition intersect ceiling
P1->>P2: wrap getToolInvocationGuard
P2->>P3: guardedConfig
P3->>P4: new invocation with programmatic options
P4->>P4: canStartBackgroundAgent, else capacity_wait
P4->>P5: derive approval config from guardedConfig
P5->>P6: agentConfig and toolConfigOverride
P6-->>P3: programmaticStatus started
Note over P3,P6: no test crosses this seam - launcher.test.ts mocks agent.js
P7->>P7: meta.meshAgentId triggers guard re-derive
P7->>P6: toolConfigOverride from buildMeshToolConfig
Note over P7,P6: covered - resume test asserts the guard denies edit
Files changed (10 of 10)
Test evidenceThis section carries no CI evidence, because none exists for this commit — that is the finding, not a gap in my reporting. Two independent API queries confirm it: The cause is structural, not a fluke:
Not verified, and why: typecheck, lint, format, and all four named test files — no CI fired on this head. The PR was self-merged by an admin 35 seconds after opening, so there was no window for a run either. The only test numbers in play are the author's own claim of 218 named tests on macOS; that is the author's local result, not evidence I can stand behind, and the PR itself marks Windows and Linux as pending #11206. I also did not execute anything — the review is static by policy, so I have not reproduced the author's run. Sandboxed verification would settle the open half of this: 中文说明代码评审我本来预期能在能力边界上找到漏洞，结果基本没有——设计是细致的，有几处初看有风险的地方其实已经处理妥当。下面把"已排除"和"未排除"的都记录下来，因为已排除的那部分正是 #11206 的评审者否则会花时间的地方。 已核查并排除：
我真正要提出的： 1. 边界的启动侧完全没有测试。 这是我希望在 #11206 合并前解决的一条。 2. 这个 commit 没有跑过 CI，因此上面所有内容都未经机器校验。 这不是代码缺陷，但它改变了本次评审的分量：我是静态阅读的，typecheck / lint / format / 四个指定测试文件从未在 3. 4. 一个属于产品决策而非代码的疑问：上限限制的是写，不是读的范围。 测试证据本节不携带任何 CI 证据，因为这个 commit 根本没有 CI 证据——这本身就是结论，而不是我汇报上的缺口。两次独立的 API 查询确认了这一点： 原因是结构性的，不是偶发： 未验证项及原因：typecheck、lint、format，以及全部四个指定测试文件——这个 head 上没有触发任何 CI。 该 PR 由一位 admin 在开启 35 秒后自行合并，所以也不存在让运行完成的窗口。唯一存在的测试数字是作者自己声明的 macOS 上 218 个指定测试；那是作者的本地结果，不是我能背书的证据，而且 PR 自己已把 Windows 和 Linux 标为等待 #11206。我也没有执行任何东西——按策略评审是静态的，因此我没有复现作者的运行。 沙箱验证可以解决这里悬而未决的一半： — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
|
Confidence: 3/5 — the design is sound and I cleared eight things I initially suspected, but the launch-side guard chain is asserted by no test and no CI ever ran on this commit, so the bar for auto-approving a core change isn't met. Going back to the proposal I wrote before reading the diff: this is essentially the design I'd have reached, which I want to be careful not to over-read as evidence of correctness — it mostly means we both looked at the same constraints and picked the obvious seam. Where it exceeds my sketch is the cold-resume half. I had assumed the boundary would be re-derived from the definition at resume; persisting What I can't get past is that I never saw this run, and nobody else has either. That's not hedging — it's the specific shape of the gap. The resume path is tested. The launch path, which is the one that executes first in production and every time thereafter, is tested only against a mock that replaces the function it calls. So the claim "the mesh read-only ceiling holds for a freshly launched mesh agent" is currently supported by reading, by symmetry with the resume path, and by the author's local macOS run. Reading is what I did, and reading is also how I nearly reported a false Critical: I was confident the nested-session background downgrade would silently run a mesh agent to completion in the foreground and then report Six months from now I think I'd mostly thank the author rather than curse them. The typed result unions are the right instinct, the narrowing is intersective so it can only ever tighten, and MCP tools fail closed three separate ways. The maintenance cost is real but proportionate: The pattern question matters more than this PR does. This is a stacked child of #11206, and steps 5, 6 and beyond will have the same shape: a Am I being a pushover here? The temptation is genuine and worth naming: the code is good, the author has admin, it's already merged so nothing I do can block it, and it's "just a prerequisite". That combination is exactly where a gate should not soften, so I'm not approving — and I'm also not requesting changes, because the PR is merged and a Deferring rather than approving, and escalating for a human call. The reasons I can't close this out myself: (1) the launch-path guard chain crosses two config derivations before reaching the child scheduler and no test crosses that seam; (2) zero automated checks ran on the merged commit, so I have no machine signal to weigh against my reading; (3) whether the read-only ceiling should also bound read scope — a mesh agent can currently read I tried to resolve an accountable maintainer deterministically and nothing came back: 中文说明信心度：3/5 —— 设计是扎实的，我排除了八处最初的怀疑，但启动侧的守卫链没有任何测试断言，且这个 commit 从未跑过 CI，因此自动批准核心改动的门槛没有达到。 回到我在读 diff 之前写下的方案：这基本就是我会得出的设计。对此我要小心，不要过度解读为正确性的证据——它主要说明我们俩看到了相同的约束并选择了那个显而易见的接缝。它超出我构想的地方在冷恢复那一半。我原本假设边界会在恢复时从 definition 重新推导；而在 meta sidecar 中持久化 我无法越过的一点是：我从未见过它运行，别人也没有。这不是含糊其辞——这正是缺口的具体形状。恢复路径有测试。启动路径——生产中第一个执行、且此后每次都执行的那条——只针对一个替换掉了它所调用函数的 mock 做了测试。所以"mesh 只读上限对新启动的 mesh agent 成立"这个论断，目前的支撑是阅读、与恢复路径的对称性推断，以及作者在 macOS 上的本地运行。阅读是我做的事，而阅读也正是我差点报出一个假 Critical 的方式：我曾确信嵌套会话的后台降级会静默地在前台把一个 mesh agent 跑完、然后报告 六个月后，我想我大体上会感谢作者而不是埋怨。带类型的结果联合是正确的直觉，收窄是交集语义所以只可能收紧，MCP 工具以三种独立方式失败关闭。维护成本是真实的但相称： 模式问题比这个 PR 本身更重要。这是 #11206 的 stacked 子 PR，而第 5、6 及后续步骤会是同样的形状：一个 我在这里是不是太好说话了？这种诱惑是真实的，也值得点名：代码是好的，作者有 admin 权限，它已经合并所以我做什么都无法拦截，而且它"只是个前置 PR"。这个组合正是 gate 不该软化的地方，所以我不批准——同时我也不 request changes，因为 PR 已合并，对已合并代码提交 选择 defer 而非批准，并上升为需要人来判断。 我无法自行收尾的原因：（1）启动路径的守卫链在抵达子调度器之前跨过两次 config 派生，而没有测试跨过这个接缝；（2）已合并的 commit 上零自动检查运行，所以我没有任何机器信号来与我的阅读相互权衡；（3）只读上限是否也应约束读取范围——mesh agent 目前可以读取 我尝试以确定方式解析出应负责的维护者，但没有结果： — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
3 participants
What this PR does
This stacked prerequisite adds the runtime seam required by mesh step 4. It launches a configured background agent with a fixed mesh identity, preserves the definition's tool restrictions under the mesh read-only ceiling, returns typed capacity and launch outcomes, and restores the same capability boundary after a cold resume.
Why it's needed
The mesh launcher must reuse the existing background-agent lifecycle without putting mesh-specific dispatch logic into that shared path. Keeping this change in a separate child PR also keeps the shared runtime hot path out of the step-4 host-session PR, as required by the implementation workflow.
Reviewer Test Plan
How to verify
Run the four named core test files. Confirm that a saturated background registry returns
capacity_waitwithout queueing, a missing definition creates no runtime, a valid definition is converted before launch, definition-level execution/disallow restrictions cannot be widened, and a cold-resumed mesh runtime still rejects write tools.Evidence (Before & After)
N/A — internal runtime contract only.
Tested on
Environment (optional)
Node.js workspace with the existing repository dependencies.
Risk & Scope
Linked Issues
Stacked prerequisite for mesh step 4 in #11206.
中文说明
这个 PR 做什么
这是 mesh 第 4 步的 runtime 前置子 PR。它使用固定 mesh 身份启动已配置的后台 agent，在 mesh 只读上限内保留 agent definition 自身的工具收窄规则，返回带类型的容量与启动结果，并在冷恢复后重新建立同一能力边界。
为什么需要
mesh launcher 需要复用现有后台 agent 生命周期，但不应把 mesh 的派发逻辑塞进共享 runtime 路径。按实现工作流把这部分单独放在子 PR，也能确保第 4 步的 host-session PR 不直接修改共享 runtime 热路径。
Reviewer Test Plan
如何验证
运行四个指定的 core 测试文件。确认后台 registry 饱和时返回
capacity_wait且不入队；definition 缺失时不创建 runtime；有效 definition 在启动前经过转换；definition 自身的 execution/disallow 限制不会被放宽；mesh runtime 冷恢复后仍拒绝写工具。前后证据
不适用——仅内部 runtime 契约。
测试环境
环境（可选）
Node.js workspace，使用仓库现有依赖。
风险与范围
关联事项
#11206 中 mesh 第 4 步的 stacked 前置 PR。