fix(manager-runtime): honor verified private steward host grants

[loopx-agent]

Goal And Delivered Outcome

A native owner-private steward remained restricted even after the operator explicitly applied the machine trusted_owner profile: every non-default manager channel was downgraded unconditionally. The existing Core binding now supplies a fresh owner-audience proof to the same machine profile at open, resume, healthy-host reuse and portfolio-scope refresh. The existing Codex adapter receives the effective sandbox.

The proof checks the current App/operator, private source, resource grant and frozen Session context. It is ephemeral and grants no tools by itself. Unbound channels, groups and workspace-only resources remain restricted; project assistants keep their independent workspace grants. No new ACL, configuration source, provider session authority or model runner is introduced.

Intended base: main, starting at 271a3d98c601d86363159711b5672cdd6be2171d. Existing acceptance: docs/architecture/rfcs/manager-runtime-profile-v0.md, within roadmap R2.

Author Declaration

• Written by: OpenAI Codex model agent, published through the LoopX Agent account.
• Specification: the manager-runtime RFC at the base above, with its native private audience acceptance clarified in this diff.

Criterion	Disposition	Owner / decisive check
Explicit persistent machine grant; no second authority	implemented	manager_runtime/machine_profile.py; missing/restricted/trusted profiles tested
Current audience/resource boundary	implemented	collaboration/conversation_binding.ts; identity loss, revocation, group and workspace-only negative cases
Session continuation and runtime readback	implemented	native admission + app-server RPC tests; grant/revoke, same Session/history, restart resume and portfolio refresh
Installed live work and desktop notification delivery	deferred	candidate must be reviewed and adopted; this PR does not implement a desktop notification transport

Scope And Continuation

Complete source slice for honoring an existing explicit grant on a verified private entry point. Audience verification stays in typed Core; Python composes the existing machine owner and provider observation. The controller only wires these owners, without raising its size budget. The registry I/O manifest changes only a source line location. Paired RFCs disclose remaining qualification. Installed live-model/Lark acceptance follows reviewed adoption and is not claimed here.

Validation

• Tested revision: 8ef9aa3
• Run state: finished
• Input classes: synthetic, public_fixture

Check kind	Result	Evidence / limitation
regression_parity	passed	New native grant test fails on pristine base with restricted instead of trusted_owner; passes on this candidate
integration	passed	tests/test_native_steward_runtime.py and tests/capabilities/test_manager_runtime_profile.py: 13 passed, including final portfolio-refresh regression
unit	passed	Core binding/scope/project TypeScript tests: 21 passed
integration	failed	Broader eight-module Python run: 102 passed, one pre-existing test_inspection_lists_registered_namespaces_without_local_refs failure (todo_replan_cadence expects completed_todos, default is effective_turns); independently reproduced at pristine base. Run preceded the final added scope test; product code is unchanged
real_entrypoint	passed	Packaged Chat settings preview/apply/readback → native private admission → Codex RPC: same Session, read-only → danger-full-access → read-only. Provider/model are synthetic; no live listener or credentials
static	passed	Ruff, source bundle verification, native premerge (direct checks, semantic/maintainability checks, risk smokes and public-boundary scan)
real_backend	not_run	Installed live model, actual Lark interaction and desktop notification delivery are not certified by the fixture

No CI status was queried or awaited.

Frontend / Visual Evidence

UI impact: none. Existing settings controls are reused without layout or component changes. The packaged settings transaction was exercised with synthetic data; its result reached the native backend and app-server RPC.

Boundary Checklist

• No private configuration, conversation text, credentials, runtime identifiers, local paths or raw evidence in the diff or PR.
• Focused bug fix using existing authority and installation boundaries.
• Every commit has a DCO sign-off.

[loopx-agent]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=xhigh

动机

已在机器设置中授权工具访问、通过本人私密 App 对话交办工作的用户，会遇到对话仍只能只读规划的情况。 例如用户先在同一对话留下工作要求，再把机器配置切换为 trusted_owner：原版仍把这个原生 steward 当外部频道而降级；本版重新核验本人绑定后启动具备原授权的线程，保留原会话和历史。

独立实测确认：私密 owner steward 能沿原生入口使用已授权的 profile，重开和刷新范围仍保持会话连续性；群、未核验绑定、仅工作区授权和被撤销的绑定不能借此获得完整工具权限。 本 PR 不创建新账户权限、独立 ACL、Goal/租约/交付权限或执行授权，也不证明真实桌面已安装采用、真实模型工具执行和 live Lark 的完整资格。 源代码与脚本化 Codex app-server 边界已验证；真实已安装桌面、真实模型及 live provider 的完整运行资格仍属既有 M1 后续验收。

改动思路

复用 Core 的当前绑定判断与原机器配置，比删除所有外部频道限制或新增 ACL 更小且更安全；Python 只组合已有证明和配置，不复制权限规则。 当前 PR 仅修复本人私密原生 steward 的有效 profile 与接续；部署、真实模型和 live provider 资格由既有 runtime 验收继续承担。

最强反对理由是：此前受限的频道现在可能获得主机工具，若只凭角色名、保存的布尔值或过期绑定，就会扩大权限。直接删除外部频道降级、只改 prompt 或另建 ACL 都不能同时解决真实 sandbox 与范围问题。本版复用当前 Core 的 App/operator/private source/resource/frozen Session 判断，再与原机器授权相交；两者任一缺失都不授予完整工具。

独立依据 spec_ref docs/architecture/rfcs/manager-runtime-profile-v0.md，spec_revision 271a3d98c601d86363159711b5672cdd6be2171d 的修改前已接受文本。Acceptance 逐项核对：1 默认 restricted；2 原配置 preview/apply/readback；3 RPC sandbox 与 prompt/AGENTS 一致；4 profile 轮换保留 Session/history；5 无关配置不轮换；6 非 Codex fail closed；7 原界面有效状态与无效配置回退；8 无既有 scoped grant 的外部 audience 仍只读。新增第 9 项是说明当前修复，不能反过来充当独立验收。第 7 项伴随界面与配置 consumer 未改，源码构建通过，当前配置 API/Session readback 验证；不将它说成真实已安装界面的资格。

具体改动

Exact head 8ef9aa3048b1e91737e27c3cacfcb665244de5c4，base 271a3d98c601d86363159711b5672cdd6be2171d；完整 12 文件 +284/-29。

conversation_binding.ts 在所有原有验证之后投影 owner_manager_audience，仅 steward 且非 workspace_only 为真；Python ChatConversationBindings.manager_runtime_owner 每次重新调用原 resolver 并核对频道。load_bound_manager_runtime_profile 组合原有证明和 manager_runtime 配置，供 runtime 与 portfolio 共用。controller 在健康 adapter 的复用之前也重新验证；有效 profile 改变才重建 upstream，保留原 Session 和可见历史。没有新增持久化 owner 标记、ACL 或 Python 权限判断源。

双语 RFC 同步说明原生 owner 例外及脚本化证据边界；registry IO manifest 只移动现有读取点的行号。新增测试覆盖默认→授权→撤回、重开/resume、范围刷新与相邻 App 隔离。有限未来重构检查已应用在共同 profile 组合处，继续把资格规则留给 typed Core；没有相关理由增加更大的框架。

对主干的风险

独立运行相关 Python 真实入口套件：151 passed，1 个无关 cadence 断言失败。另有 17 个 TS binding/scope/project 用例通过。自己新增的当前边界反例通过：已有健康线程时，伪造 saved owner 字段、改 source/operator 或撤销绑定会在新 RPC 前拒绝；仅撤回机器 profile 则同 Session 回到只读。这里的 Core、配置、Session、controller 与 JSON-RPC 路径实际执行，provider/model 是记录请求的脚本化端点，不证明真实模型工具效果。

将本版原生 grant/restart 与 workspace-only 两例原样放到不可变 base：1 failed（原来仍 restricted，无法达到 trusted_owner），1 passed（隔离保持）；候选两例均通过，能区分这次真实缺陷。

当前失败 test_inspection_lists_registered_namespaces_without_local_refs 在相同 base/head 命令均为 count_unit: effective_turns 对 completed_todos 的同一断言。本 PR 没改 cadence catalog/配置实现或该断言，manager 改变另有通过证据；保留给原 cadence owner，不能称整个 Python 套件全绿。原生 premerge 5 direct/11 selected 均通过、无 manual hold；scoped Ruff、全树语义与边界检查通过，advisory 无支持的新 vocabulary carrier（不证明动态语义）；Dashboard/Chat 源码构建通过，仅 bundle-size 提示。没有查询、轮询或等待 CI。

restricted 默认和外部限制不变；开启是原机器明确授权加当前 audience 证明，安装/可用/旧 Session 字段不算授权。权限条件是 enforced，不是 guidance；名称只表示 audience 的派生事实，不能扩大成独立 agent 生命周期、merge、Goal、lease 或 connector 权限。

我的整体评价

APPROVE，无阻塞发现；本次是有界 runtime 修复的 justified_increment。它让既有授权可用于同一真实入口并保留接续，所有实质反例有当前证据。部署、真实模型及 live provider 完整资格仍需后续独立验证；上述无关基线失败仍公开保留。

GitHub 账户与作者相同，因此发布 COMMENTED 自审批准结论，不能把它叫正式 APPROVED；平台 reviewDecision 与原生 closeout/readiness 另读回。本结论不授予合并权限。

English verdict: APPROVE — 8ef9aa3; fresh existing Core owner-audience proof and the explicit machine grant compose without granting groups, workspace-only or stale bindings host access. Native continuity, revocation and independent impersonation counterexamples pass; base reproduces the original downgrade. The identical unrelated cadence assertion remains red. Installed live application/model/provider qualification is not claimed.