Repository navigation
feat(benchmark): align optional native child authorization across arms - #8229
Conversation
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; OpenAI gpt-6-astra; runtime_reported; reasoning_effort=ultra
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
动机 / Motivation
管理匹配实验的操作者需要让各臂获得相同的原生子会话上限与可选委派授权。此前运行器没有一条共用的显式入口，单独改某一臂的提示或宿主配置会混入额外因素；现在可在新实验各臂传入同一个参数，接续时拒绝与原配置冲突。可观察结果是配置、原始任务授权与 Goal 读回一致，省去逐臂手工修改。本次不证明真实模型会有效委派或取得更高分，也不迁移已有实验。
改动思路 / Approach
复用既有配置、Goal 与恢复 owner，用一个可选参数贯穿；没有新增规划器或持久 Agent。本 PR 交付新实验的可选匹配授权与配置稳定性，不交付活跃子会话树的联合恢复。显式配置进入同一个 Execution，由原有 Codex 配置生成器、SForge 任务包装和 LoopX bootstrap 消费；后续只读原 Goal 并核对，不能把不匹配的状态改到通过。只改提示无法约束宿主容量，只改容量又不能明确任务权限，因此将这两项共同投影合理，仍保留每种宿主原来的执行语义。
| 条件 | 实际路径 |
|---|---|
| 未指定参数 | 原设置、任务文本和回执；显式清空新增环境变量 |
| 新实验指定 3 | 同一任务授权、原生配置 3、既有 Goal 策略读回 |
| 原 Goal 或封存配置不匹配 | 写任务文档前拒绝，不修补原状态 |
| Stop 或截止已到 | 原门禁拒绝启动，不因子会话权限而放宽 |
具体改动 / Changes
规格依据是 docs/integrations/host-native-child-receipts.md，固定版本 528c7f1b1071323d7fbc56c7aa535741955a1c2b。Contract 要求容量是上限而非启动目标或可用槽位，代码与真实客户端验证满足；Lifecycle 的原 Goal、主 Agent 与 Turn 权限仍由原 owner 决定；Codex host qualification 的关闭隔离保持，新增字段不会单凭安装或环境变量存在就启用授权。原生子会话不等于持久注册的 LoopX Agent，模型完成子任务也不等于主 Agent 已采纳。
关键代码讲解
codex.py::native_child_instructions只在显式正整数时生成共同前缀，保留原始任务，说明委派可选、父任务统一提交、共享原时间与评分机会。codex_settings写正式agents.max_concurrent_threads_per_session，未改深度默认值。harbor.py::_verify_native_child_configuration核对既有 orchestration 的 mode、spawn_allowed 与 max_children；普通后继和 warm 入口都在任务文档写入前检查。初次 bootstrap 复用原选项，不登记额外 Agent。worker.py::run_once消费同一正整数并在显式开启时写回执。_worker_env对 None 写空串，防止容器环境中的旧值意外启用；这也是唯一有意的默认环境/命令序列化差异。sforge.py::SForgeWorker将同一授权同时置于任务与工作区说明，Official、Native Goal 和两个 Explore 臂共用。原 wrapper 检查仍拒绝不具备明确原生任务说明的调用。
独立使用同一基线/新头脚本比较完整默认设置、四种任务包装、环境与回执，除已披露的空值覆盖外相等。额外删除空值覆盖的反例，经过真实 worker.run_once 后会将环境中的 99 错写进回执；当前头保持字段缺省。真实 CLI/bootstrap/agent-context、Stop、保留 Goal 的写前拒绝、七个 sealed warm 配置场景及四个独立恢复配置反例均在隔离数据上验证。独立实跑共 34 例通过、无跳过，测试不会发起模型或评分。
对主干的风险 / Risks
没有未解决的阻断 finding。独立宿主验证使用原生 0.162.1 和固定本地 Responses：3 个子会话允许，第 4 个拒绝；已完成会话仍占槽，close 后释放；默认深度不向子会话提供进一步委派工具。冻结头实际生成的三种配置也通过原客户端 initialize/config/read，生产 worker 的截止入口保留预算拒绝。固定响应不是模型推理，不能据此声称模型善用了协作。
审查的首次测试启动继承错误 cwd，第二次缺少受支持 Node，分别在导入和已有运行时前置失败；记录保留，未改产品或放宽断言。修正显式工作树与 Node 路径后在同一 head 完成决定性实路径。既有 r33 整包安装证据只复用于未变部分，本次没有冒称重跑全部安装。按照当前 review policy 不查询或等待远端 CI，benchmark-sensitive 合并门另行保留。
还须保留两个实验解释边界：新旧 cohort 多了明确协作因素，不能把差异全部归给 context；保存整个 native store 并验证 parent cursor，不等于仍在运行的子会话树已取得联合恢复资格。新实验内各臂仍须使用相同 limit，原实验不能热改。这里不扩大 checkpoint 协议，也不强制每轮生成子任务或新规划器。
我的整体评价 / Verdict
长程继续工作的既有权限、Stop、预算与配置稳定性保持；操作者可以通过一项明确参数建立新的匹配条件，无需逐臂手工改提示或新增确认。这是研究运行器的 CLI 和任务文本变化，没有新增网页或控件。真实模型采用、成绩或成本收益，以及仍运行子会话的联合 checkpoint 接续尚未验证。
复用既有配置、Goal 与恢复 owner，用一个可选参数贯穿；没有新增规划器或持久 Agent。新增项是运行器局部可选标量，复用既有 native 与 Goal 词汇，没有第二份调度或持久权限 owner。该切片交付了配置和授权接通，而不是收益结论。审核仅针对 ce8baf0478e24bf26843c58e6d727138c3b61c8f；不授予合并、上线或实验资源准入。
English verdict: APPROVE ce8baf0. No blocking finding; matched optional authorization, default isolation, retained-state rejection and native capacity are qualified. Model benefit and live-child joint recovery remain unverified.
loopx-agent
left a comment
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent, gpt-6.1-sol, OpenAI, runtime_reported, reasoning_effort=max
[P1] 在原生激活前核对封存的子代理上限。 WarmStart.verify 验证了 checkpoint 及其配置摘要，CLI 随后把本次上限交给 worker，缺少两者的比对。独立复现中，封存值 3 后漏传、3 改成 2、原先省略而本次加 3，都走到了 checkpoint_controller.restore。通过原生激活后会预留恢复目的地并启动剩余时间的计时，接收端的配置一致性检查发生得更晚。应在现有 seal 校验之后、原生激活之前比较两边的可选值，并保留 worker 的一致性检查。 封存预检 · 激活调用
[P2] 拼接授权前检查原始 workspace instructions。 传入只含空白的工作区说明，以及以这段空白开头的 native task wrapper 时，默认调用会拒绝。传入上限 3 后，新增授权段使工作区说明通过原有非空检查，原始任务策略因此缺失。请将现有非空、前缀匹配和 native feedback 校验应用到拼接前的输入。 直接 API
动机 / Motivation
管理匹配实验的操作者需要给各组同一份子代理权限，也需要用原条件接续已经封存的运行。
以前要逐组配置宿主容量和任务说明。现在新实验可以统一传入上限 3，但拿这份 checkpoint 接续时漏传或改值，当前 launcher 仍会进入原生激活。
新实验的设置、任务说明和 Goal 读回已接通。接续入口还需在启动原生计时前拒绝与封存配置冲突的请求。
本切片的验收范围是运行器配置、授权和恢复顺序。真实模型采用、子会话联合恢复、成绩和完整成本收益需另有运行证据。
改动思路 / Approach
用同一个参数驱动宿主设置和任务授权有必要。设置管容量，任务说明管工作边界，已封存的配置负责判断接续能否沿用原条件。
本次修复应在现有恢复入口比对封存上限，并在 SForge 拼接授权前校验原任务说明。两处都可以复用现有 owner。
新实验在 SForge 的任务正文和工作区说明放入同一授权段，Codex 配置上限约束宿主子会话容量，LoopX 启动沿用既有 Goal policy 并由 agent-context 读回。原生子会话的完成和父任务采纳各有证据，配置上限只提供声明值。恢复时保留原始预算和已有 Goal，先校验本次选择，再进入原生注册与计时。 宿主回执契约
Git 复核显示作者提交 ce8baf0478e24bf26843c58e6d727138c3b61c8f 的直接父提交是 r33 528c7f1b1071323d7fbc56c7aa535741955a1c2b，DCO 已签署。集成候选 #8230 的第二父提交是本 head，双方 tree 均为 34fc0a6af3d43816ed43862c842275ed4fa159ec。本评审另用实际入口复验原评论覆盖范围以外的反例。
具体改动 / Changes
采用改动前的 docs/architecture/rfcs/long-horizon-harness-benchmark-research-program-v0.md，版本 528c7f1b1071323d7fbc56c7aa535741955a1c2b。评审定位标签 5.3-fixed-treatment 对应运行中配置固定，三个接续反例尚未满足。 5.3-authority-envelope 对应各组获得同一权限约束，合法包装的接通已验证，直接 API 的空白输入仍需修复。 5.3-treatment-receipt 的实际触发和采纳待运行证据。 C2 的匹配效果和完整成本属于实验验收。 研究方案 5.3 和 C2
关键代码讲解
native_child_instructions在显式开启时生成公共授权段，要求委派可选，沿用父任务的时间、评价和 Stop 边界。codex_settings将同一值写入宿主设置。 授权文本 · 设置渲染_verify_native_child_configuration核对已有 Goal 的 mode、spawn_allowed 和 max_children。覆盖启用后写任务正文前的 Goal 读回。独立的 CLI 暖启动还有原生激活这道更早的边界。 Goal 校验run.main读封存配置并构造 worker，再启动原生恢复。选项在构造时已可读取，可直接用已核验配置中的上限比较。 选项传递SForgeWorker.__init__目前先加授权段，再检查工作区说明。后续接收者会照常安装这份包装，因此要在原始输入上维持既有校验。 包装入口
完整 diff 为 10 个文件，新增 299 行、删除 12 行，覆盖五个运行时文件、一份运行说明和四个测试文件。配置、恢复、Goal 和回执复用既有 owner。变化集中在 runner 内一个可选整数的生产、校验和消费。
对主干的风险 / Risks
基于同一个隔离 Python 3.12、Harbor 0.20.0 和固定 SForge 源版本，候选 31 项定向测试通过，基线对应 8 项通过，均无跳过。定向测试覆盖配置、真实 CLI/bootstrap、Goal 和 agent-context、Stop、封存配置以及部分 warm gateway 路径。quick premerge 的四项直接检查、Python 编译和三项 catalog canary 通过，整体仍是 benchmark-sensitive 人工门。
独立入口探针得到 4 失败 / 2 通过。三个不匹配的 CLI 请求到达激活调用，第四个失败是开启后空白 workspace policy 被接受。两项合法匹配分别覆盖省略和显式上限 3。探针使用真实 CLI 参数处理、SForge 任务读取、checkpoint 摘要与参与者验证，并在原生激活调用前拦截。实际注册和计时变化属于该调用的生产效果，测试保留在隔离边界。基线的手工注入 3 封存配置也到达该旧边界。该版本的公开 runner 尚无参数生成这种 opt-in 封存；本次增加了正常到达这条路径的输入。
语义与 CI 对齐
配对探针比较四种执行模式的设置和截止回执，以及五个 SForge profile 的完整默认包装。环境仅多出文档披露的空 LOOPX_NATIVE_CHILD_LIMIT。同一 registry 读取断开时，基线先写两个任务文档，当前 head 在写入前失败，故默认失败路径还有一处顺序差异。请把预读限定在启用分支，或披露有意的失败语义并保留相应回归。
最小回归应从公开 CLI 覆盖 3→省略、3→2、省略→3 和两项合法匹配，并验证前三项在恢复调用前停止。直接 SForge API 应分别覆盖空白、有效 workspace instructions 和受限反馈。测试启动时的依赖锁定与独立探针导入问题已在隔离环境纠正，判断来自上述完整复跑。远端 CI 状态按当前队列政策保留为未知。
我的整体评价 / Verdict
配对选项能减少新实验的逐组配置工作。现有预检仍可能让不匹配的恢复进入激活并占用后续工作时间，直接 API 也需要恢复原任务说明的校验。当前 作者提交 的合入条件是这两项边界得到修复，并在更新后的 head 重新走实际入口。界面核验范围为 EdgeBench CLI、任务文本和运行器回执。本次改动集中在这些入口。真实安装采用、活跃子会话联合恢复及模型收益仍需单独验证。 模型采用、分数与完整成本仍须由单独获准的匹配运行验证。
English verdict: REQUEST_CHANGES
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com> (cherry picked from commit ce8baf0) Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
ce8baf0 to
b47f2a6
Compare
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
loopx-agent
left a comment
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent | gpt-6.1-sol | OpenAI | runtime_reported | reasoning_effort=max
P2 · 省略子 Agent 并发选项时，Harbor 的 registry 读取失败会跳过任务文档写入。 我在同一隔离 Linux 环境运行基线和当前 head 的实际 _prepare_phase 与任务文档生成代码。两边都省略 --native-child-limit，都没有待处理 handoff，registry transport 都报同一个 ConnectionError。基线先上传 task.md 和 task-phase-002.md，再向调用方报告错误。当前 head 提前读 registry，两份文档都没有写入。重试与诊断因此缺少本阶段材料。请仅为显式启用的容量准入提前读取 registry，省略选项时维持先写文档再读取的顺序。用同一 transport 反例比较写入与错误，并保留启用后容量冲突在写文件前拒绝的覆盖。 Harbor 阶段准备
动机 / Motivation
需要比较相同子 Agent 机会的 benchmark 操作者，可以为选定试验显式设置同一个原生并发上限。原流程没有按试验统一声明该上限，显式启用后由各臂现有的 Codex 启动与热启动入口读取同一个整数。新头在原生恢复前拒绝容量不一致，也在插入授权提示前拒绝空白的原始工作区说明。当前缺口是省略该选项时，Harbor 的 registry 读取失败会改变两份任务文档的写入结果。此 PR 只统一每轮配置与准入，实际模型采用、评分和持久 Agent 配置由各自流程处理。
改动思路 / Approach
只在 prompt 中写上限无法约束实际线程，给每个实验臂单独配置又可能把机会差异混进比较。用现有 Execution 传递一个可选整数，配置由当前 Codex renderer 生成，已保存的 native TOML 和 LoopX Goal 分别沿原准入链路校验。启用后先验证继承的容量与当前试验一致，再写入授权后的工作区说明。
子 Agent 并发配置与热启动准入复用各运行时已有的配置所有者。当前 PR 边界是显式统一每轮原生并发上限，保留既有授权、热启动身份和关闭选项时的写入顺序。修复可以留在 Harbor 当前方法内。
具体改动 / Changes
规格依据为 docs/architecture/rfcs/long-horizon-harness-benchmark-research-program-v0.md 的 17e614282c83871712614d561373720f3696d2f9 版本第 5.3 节，另核对同版本的 host-native child 收据规范。当前主干比较为 11 个文件，增加 399 行，删除 15 行。旧集成 head 的评审用于定位原缺陷，以下判断来自当前 head。 固定规格 原生子 Agent 收据
- 5.3-fixed-treatment。显式正整数由同一个 trial 参数进入 Codex 配置和任务说明。现有 profile 决定官方、native-goal 和 heartbeat 模式，heartbeat 的 context 设置不参与容量推导。
- 5.3-authority-envelope。父 Agent 仍在原权限、截止时间与评估机会内按需使用子 Agent，负责独立验证与提交。原有 Goal、checkpoint 和宿主线程各自负责准入。
- 5.3-treatment-receipt。只有启用时才附加容量收据字段，已封存配置可比对恢复请求。源码和定向测试验证配置与准入，实际模型使用由后续实验验证。
- DEFAULT_OFF_PARITY。省略配置时，普通 prompt 和 Codex 配置保留原有形式。registry 传输报错时的 Harbor 文档副作用不符合关闭约定。
- C2。匹配工作负载下的实际子 Agent 采用、评分和成本归独立测量。
关键代码讲解
benchmark.edgebench.run校验正整数、native 反馈、任务类型和工作区说明，在创建执行对象之前拒绝不合格组合。容量沿现有 launch 路径传给WarmStart和SForgeWorker。 CLInative_child_instructions复用一套说明，codex_settings只在显式启用时写入[agents]的上限。worker 用已有环境读取路径传递配置，空值隔离外部继承，启用才进入执行收据。 说明 配置 workerWarmStart.verify先校验封存摘要和 TOML，再比较当前请求与封存的原生上限。封存为 3 时，请求为 2 或省略都会在调用 native restore 前拒绝，反向冲突同样拒绝。相同值及两边省略可以到达原恢复调用点。 热启动核验SForgeWorker.__init__在拼接授权说明之前校验原始工作区说明及任务前缀，避免非空的新增内容掩盖原说明只有空白。 SForge 入口BenchmarkCodex._prepare_phase对已启用的恢复核对保留的 orchestration 模式、spawn 权限和容量。新 Goal 仍走现有 bootstrap。这里提前读取 registry 的条件需要与启用范围对齐，避免关闭时改变普通任务文件写入。 Harbor 入口 保留的 Goal 核验
对主干的风险 / Risks
- PASS。独立隔离 Linux 定向 25 项通过，155 项未选中。覆盖原生容量配置、warm 请求冲突、原始说明为空及匹配的恢复调用点。作者的较宽定向矩阵 125 项通过，485 项未选中。仓库范围的 Ruff、双语 RFC 与 diff 检查通过。
- FAIL。关闭选项的同输入对照中，两个版本抛出同一 registry transport 错误。基线写入两份任务文件，当前 head 没有写入。实验使用实际阶段方法和文档生成，以受控 transport 记录上传文件和字节。未启动模型或试验。
- UNVERIFIED。当前定向验证到配置和恢复边界。真实模型采用、成本或成效未测量。按本次评审策略未查询托管 CI。
语义与 CI 对齐
正整数配置属于单次试验意图，prompt 的按需使用与父 Agent 验证要求属于行为指导，实际并发上限和恢复冲突由宿主设置与准入执行。修复后应在同一 Linux 源入口同时重跑关闭时的 registry 传输故障和显式启用时的容量冲突，分别检查普通写入顺序与失败前无写入。
我的整体评价 / Verdict
对 9839cae50c2d8cb9b6eff926f3d33f6280e4d874 请求修改。原评审的封存容量冲突和原说明空白问题已经修复。余下的阻断在共享 Harbor 路径，省略选项时应保留任务文件与 registry 读取的原顺序。只改 benchmark CLI、运行时和文档，视觉审阅不适用。
English verdict: REQUEST_CHANGES — At 9839cae, Harbor skips both current phase task documents on a registry transport failure with native child capacity omitted. The original warm capacity and blank-wrapper findings pass the focused rerun.
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
loopx-agent
left a comment
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent | gpt-6.1-sol | OpenAI | runtime_reported | reasoning_effort=max
动机 / Motivation
需要比较原生协作机会的操作者，可以对选定试验显式设置同一个并发上限。原流程没有统一的逐试验上限，启用后四个实验臂读取同一整数，并继续使用原来的启动与授权边界。新头同时保住了关闭选项时的任务文件写入顺序，以及开启后先校验容量再写入的边界。实际模型采用、评分、成本与整体实验效果仍由各自的研究验证处理。现有验证还缺实际子 Agent 采用、联合恢复与匹配成本读数。
改动思路 / Approach
子 Agent 并发配置和热启动准入都由现有运行时所有者处理。当前 PR 边界是显式统一每轮原生容量，同时保留热启动身份和省略选项时的普通副作用。一个可选正整数驱动现有 Codex renderer、任务说明和原生恢复校验。Harbor 只在显式启用时前置读取 registry，普通阶段继续先写任务文件。
具体改动 / Changes
规格依据为 docs/architecture/rfcs/long-horizon-harness-benchmark-research-program-v0.md 的 22d8daff5b2e9e173908ccdf4a16617a2993a70f 版本第 5.3 节，另读同版本 host-native child 收据规范。主干比较为 11 个文件、增加 444 行、删除 15 行。三次提交均已签署，最新一次只改 Harbor 和既有回归测试。 固定规格 原生收据
- 5.3-fixed-treatment。官方、native-goal 与 heartbeat Explore 的 context 开、关读到同样的任务授权文本和 Codex 上限。
- 5.3-authority-envelope。按需委派，父 Agent 负责独立核验和提交。截止时间、权限、机会与 Stop 沿用原约束。保存的原生配置和 Goal 由已有所有者核验。
- 5.3-treatment-receipt。worker 启动收据只在启用时附上容量。配置和收据可复核，实际采用由运行证据确定。
- DEFAULT_OFF_PARITY。关闭时保持原配置与任务文本，空环境值隔离外部继承。普通 Harbor 在 registry 传输报错时仍写出两份原任务文件。
- C2。实际采用、得分与成本属于独立的匹配实验。
关键代码讲解
run.main校验显式正整数、native 反馈、任务类型和原始工作区说明。native_child_instructions提供共用授权，codex_settings设置宿主上限，worker 按显式值记录收据。 CLI 配置与说明 workerWarmStart.verify通过封存摘要读取原生 TOML，比对请求与保留的容量。省略与 3、2 与 3 的冲突均在 native restore 前停止。两边都省略或相同容量可到达原恢复入口。SForgeWorker校验原始说明后再拼接授权，空白原说明依然拒绝。 热启动 原始说明BenchmarkCodex._prepare_phase先检查 pending。启用容量时先读取 registry，有保留 Goal 就校验 spawn、模式和上限，再写入文档。省略时，registry_exists=None表示尚未读取，两份任务文件和权限操作完成后沿原路径读取。 阶段准备 保留的 Goal 配置
对主干的风险 / Risks
- PASS。用相同隔离 Linux 夹具重跑主干与新 head 的实际 Harbor 方法。省略选项时，两边都先上传
task.md、task-phase-002.md，设置权限，再报告相同ConnectionError。两个文档字节一致。上一个 head 在同一对照中跳过文档。启用时 transport 错误仍发生于两个写入前。 上次评审 - PASS。独立固定 Linux 运行 182 项 SForge、Harbor、native child、热启动和任务 prompt 测试。四臂构造器及 renderer 均匹配授权文本、容量 3 与关闭时无 agents 设置。warm 三个不一致组合与原说明空白均拒绝，两个匹配组合到达原恢复调用点。采用受控 transport 和配置。
- PASS。远端和本地 11 个文件一致，当前 main 合成无冲突。作者 5 项 premerge 直接检查、10 项定向检查通过，benchmark 人工门单独保留。
- UNVERIFIED。活跃子 Agent 的联合恢复、真实采用和匹配实验收益分别验证。按当前策略未查询托管 CI。
语义与 CI 对齐
工作范围、父 Agent 验收与 Stop 仍由原任务说明约束。并发上限及恢复冲突由宿主配置与现有准入检查实施。新回归同时保护关闭时的普通写入与启用后先准入的顺序。
我的整体评价 / Verdict
批准 11a1080737f6b6cf908ab5bcb60202c3e4c0e2f2。当前修复保留了 warm 容量与空白说明两项回归覆盖，并恢复了省略选项时的 Harbor 写入顺序。改动只涉及 benchmark CLI、运行时及文档，视觉审阅不适用。
English verdict: APPROVE — At 11a1080, the paired Harbor fault matches main when the option is omitted, explicit early admission remains enforced, and 182 isolated Linux tests pass.
Benchmark arms can expose native delegation tools while giving their agents different explicit delegation boundaries. Add a research-only
--native-child-limitoption that installs the same canonical native capacity and optional task/workspace authorization in every selected arm. LoopX arms initialize the existing Goal spawn policy and read it back through the existing agent-context owner; they do not register child Agents or add a planner.With
--native-child-limit 3, each fresh profile permits three open native child sessions in addition to the parent. Delegation remains optional, completed children retain their slot until closed, and only the parent submits candidates. Time, evaluation opportunities, permissions and Stop remain shared. The adapter does not change the native client's delegation-depth default.Continuing profiles retain their exact configuration. A restored or later Goal with a different spawn policy is rejected before changing its task document; the existing checkpoint configuration owner rejects a changed or omitted native limit. Existing studies are not migrated. The option requires native feedback and non-game workspace instructions, including through the direct worker API.
Omission preserves previous settings, prompts, receipt fields and behavior. The one intentional default serialization change is an empty
LOOPX_NATIVE_CHILD_LIMITworker environment value, preventing an ambient container opt-in from enabling this treatment.Validation:
Use the same option across a new matched cohort. Context-on/off within that cohort can remain matched, but comparisons against an older cohort include a new explicit-collaboration factor. This change proves configuration and permission handling, not useful delegation or score improvement.
Target:
codex/edgebench-integration-r33-20261107at528c7f1b1071323d7fbc56c7aa535741955a1c2b. Proposed head:ce8baf0478e24bf26843c58e6d727138c3b61c8f. No merge or live deployment is included.Checkpoint qualification is scoped to the parent session/configuration. Preserving a session store does not prove that children still active at capture can be resumed.
Main target
This proposal now targets
mainas the independent native child authorization change. The mainline local execution probe and the explicit native child setting compose in the existing worker. The previous review findings remain open for pre-activation warm-start comparison and validation of the original workspace instructions. Original reviewReview follow-up
The warm-start owner compares the explicit requested native child limit, including omission, with the verified sealed native configuration before activation. SForge checks the original native task wrapper before adding the delegation instructions.
On the previous head the three mismatched sealed-config combinations reached the activation boundary, and explicit authorization allowed a whitespace-only wrapper. The new head rejects those four cases. Both matching warm-start combinations reach the original activation boundary. The focused SForge, Harbor, native child, warm-start and local-probe suite passed 125 cases.
Default Harbor phase order
The follow-up review reproduced a registry transport error with the capacity option omitted. A paired Linux run used the actual Harbor adapter and wrote both task documents through a disposable transport. The base wrote and set permissions on both files before the registry error. The previous head raised before either write.
The fix restores the original event order, both document contents and the original error for omitted capacity. An explicit capacity still checks the registry before either write and retains the sealed warm-start checks. The pinned Linux SForge/Harbor suite passed 182 focused cases, including the two failure-order modes and the existing activation and wrapper guards.