[Bug] Session subagent model allowlist is bypassed when a call omits provider/model (0.1.6-alpha.2)

[xie-tj]

Summary

When a Session has the model-selection allowlist enabled (subagent/model-selection-policy), a subagent call that omits provider/model skips the allowlist entirely and can start a child on a route the user never authorized.

Reproduced on 0.1.6-alpha.2 (Web profile, dsh web).

Reproduction

1. Settings → Plugins → Subagent: enable model selection, allow only e.g. openai-codex/gpt-5.6-luna and opencode-go/deepseek-v4.1-flash.
2. Confirm the catalog:

list_subagent_models()        -> openai-codex, opencode-go
list_subagent_models(provider: "openai-codex") -> openai-codex/gpt-5.6-luna

3. Delegate without naming a model:

subagent(description: "report your model", prompt: "Reply only with your exact runtime model identifier.")

Observed: the child starts and answers gpt-5.6-terra — the parent Agent's route, which is not in the allowlist.

Expected: rejection before child creation, since an enabled Session "always carries an exact allowlist" (per the Agent Note 2026-08-24-user-authorized-subagent-model-routes).

Root cause

packages/subagent/tool-subagent/src/model-selection.ts, assertAllowedModelSelection():

// before
if (policy === undefined || !hasDelegationModelRequest(request)) return

The guard returns early unless the call supplied a model-facing field. But the effective route can also come from Config.agentOptions, provider.agentRouteDefaults, or the parent Agent's inherited route — and src/index.ts only preflighted when a model-facing field or configured LLM selection was present:

// before
const requiresRoutePreflight = hasDelegationModelRequest(modelRequest)
  || hasConfiguredLlmSelection(config.agentOptions)

So an omitted-route delegation reached ctx.subagents.start() on an unchecked route. Naming the model explicitly is rejected correctly — only the omitted path bypasses the policy.

Note this also means list_subagent_models output and the enforced route set disagree: the catalog is documented as advisory, but for the omitted path nothing else constrained the route at all.

Local fix I validated

Enforce the policy on the effective route from every layer, and preflight whenever a policy exists:

// assertAllowedModelSelection: drop the request-field guard
if (policy === undefined) return
const provider = requested?.provider ?? parentOptions.provider
const model = requested?.model ?? parentOptions.model

// index.ts execute(): preflight whenever a policy is present
const requiresRoutePreflight = modelSelectionPolicy !== undefined
  || hasDelegationModelRequest(modelRequest)
  || hasConfiguredLlmSelection(config.agentOptions)

After this, the same call rejects before child creation:

child LLM route "openai-codex/gpt-5.6-terra" is not allowed for this Session

and an explicitly allowed route still starts and reports gpt-5.6-luna.

Behavior change to be aware of: with an enabled policy, a Session whose default/inherited route is not in the allowlist will now reject instead of silently delegating. Deployments that want a default child route must list it.

Evidence

Branch (fork): xie-tj/deepseek-harness, agent/subagent-effective-route-authorization, commit c19f4043d8, based on master@ddefc45fbc (0.1.6-alpha.2). 21 files, +183/−57.

Validation in that worktree:

• pnpm exec vitest run packages/subagent/tool-subagent/tests — 131 passed
• pnpm run typecheck — passed
• pnpm exec vitest run --config vitest.snapshot.config.ts -t "subagent-dsh-sdk-dynamic-route" — passed
• pnpm run test:docs — 20 gates passed

The change covers: unit tests for parent-inherited / configured / provider-default routes outside the policy (all rejected before child creation, plus an authorized provider default that still starts), an SDK snapshot that now omits the route and inherits it through a real dsh --profile sdk child runtime, both README languages, the two owning Agent Notes, a new Agent Note Effective subagent route authorization, and the generated persistence catalog.

CONTRIBUTING.md says external pull requests are not accepted, so I am reporting it here rather than opening a PR. Happy to hand over the branch or a patch if that helps.

Related

• Host setting subagent.maxDepth is not enforced on delegation paths that call SubagentRuntime directly (workflow / spawn_teammate / ralph) #7098 — same shape: a Host policy is not enforced on delegation paths that reach SubagentRuntime directly.
• Clearly show the subagent model and let user change it on the fly #7116 — asks to show which model a subagent runs; this report is a case where the running model can differ from what the allowlist suggests.

[yamingmou]

EN / English

What we can add from the sources — as a boundary, not a verdict. @xie-tj, we went to read this path because a nearby form of it (the cost-tier side of the same delegation gate) came up in a thread we were already in — #5973. Four things we could verify, and one question we would ask instead.

① The allowlist check returns early unless the call itself names a route. assertAllowedModelSelection gates on hasDelegationModelRequest(request) alone — master packages/subagent/tool-subagent/src/model-selection.ts:145 and the published dsh-tool-subagent/lib/index.js:92 are the same line:

:145  if (policy === undefined || !hasDelegationModelRequest(request)) return

The predicate is "did the request carry provider / model / reasoning_effort" (master :76 = npm :45-47). A call that names nothing never reaches the route comparison at all.

② The function says so itself, in its own docstring. master :132-133 = npm :84-85:

Pure inheritance remains outside this policy because no model-facing choice occurred; any explicit route or effort field must resolve to an allowed route.

③ The Agent Note says the same thing — one paragraph after the sentence cited in the report. The report quotes 2026-08-24-user-authorized-subagent-model-routes.md as "an enabled Session always carries an exact allowlist". The sentences that follow it in the same section are:

A call that supplies no selection field retains configured or inherited routing because the model made no route choice.

and, immediately before it:

The delegation executor independently rejects any explicit provider, model, or effort selection whose effective provider/model route is outside the Session list…

Read together, "always carries an exact allowlist" appears to mean there is no unrestricted mode — the scope is set by the next sentences, which bound explicit selections.

④ master and the published build agree — so this is not a fix awaiting release. The early return and the docstring are character-for-character the same on master and in 0.1.6-alpha.2. We checked precisely because "already fixed upstream" is the first thing we try to falsify on a report that is 2 days old.

The question we would ask instead. The behaviour above looks deliberate, so the useful question seems to be about scope of the authorization, not about a missing check. There are three authorities in play on this path, and they do not line up:

layer	what supplies the child route	is it bounded by the user's allowlist?
the call names a route	the call	yes — rejected if outside the list
Config.agentOptions names a route	the deployment layer (the 08-18 note calls these deployment-owned defaults)	no — the allowlist gate never runs
nothing names a route	configured or inherited routing	no — pure inheritance is explicitly outside the policy

⇒ So: is the intended scope "choices the model makes", or "whatever route the child actually runs on"? If it is the former, the current behaviour is the documented design and the report's expectation is one sentence wider than the Note. If it is the latter, then the middle row looks like the interesting one — a deployment-owned route can reach a child in a Session whose user has authorized a different list — and that would be a policy-scope decision rather than a defect in this check.

We are not claiming either. We are noting that the Note's own wording reads as the former, while the report's "Expected" clause reads as the latter, and that gap looks worth resolving in one sentence of documentation regardless of which way it goes.

Honest boundaries. Static reading of the published packages and of master — we did not reproduce your run, and we do not have your settings composition (which toggle was on, and whether Config.agentOptions carried a route in that profile). Line numbers differ between the two systems and are given in pairs for that reason; identifiers are the stable part. If your Web profile had no configured route fields, then the third row is the one that applies, and the child inheriting the parent's route is what the Note describes as intended.

Authorship note: reproduced and documented by me in real-world usage; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版 / ZH

我们能从材料里补的 —— 是一处边界，不是一个判词。 @xie-tj，我们读这条路径，是因为它的邻形态（同一个委派闸门的成本侧）出现在我们已经在跟的 #5973 里。以下四点是能核实的，外加一个我们更想问的问题。

① 除非「调用自己点名了路由，否则白名单检查会提前返回。** assertAllowedModelSelection 的门控只有 hasDelegationModelRequest(request) 一个条件 —— master packages/subagent/tool-subagent/src/model-selection.ts:145 与已发布的 dsh-tool-subagent/lib/index.js:92 是同一行：

:145  if (policy === undefined || !hasDelegationModelRequest(request)) return

判据是「请求里有没有带 provider / model / reasoning_effort」（master :76 ＝ npm :45-47）。一个什么都没点名的调用，根本走不到那一步的路由比对。

② 这个函数在自己的注释里就写明了。 master :132-133 ＝ npm :84-85：

Pure inheritance remains outside this policy because no model-facing choice occurred; any explicit route or effort field must resolve to an allowed route.
（纯继承不在本策略范围内，因为没有发生面向模型的选择；任何显式的路由或 effort 字段必须解析到白名单内的路由。）

③ 官方 Agent Note 说的是同一件事 —— 就在报告引用的那句的下一段。 报告引用 2026-08-24-user-authorized-subagent-model-routes.md 说"启用的 Session 总是携带一份精确白名单"。而同一节里紧跟其后的句子是：

A call that supplies no selection field retains configured or inherited routing because the model made no route choice.

以及紧接在前的一句：

The delegation executor independently rejects any explicit provider, model, or effort selection whose effective provider/model route is outside the Session list…

合起来读，「总是携带一份精确白名单」看起来是在说「不存在不受限的模式」—— 而作用域由紧接着的句子界定：它约束的是显式选择。

④ master 与已发布构建一致 —— 所以这不是"等发布"的修复。 那句提前返回与那段注释，在 master 与 0.1.6-alpha.2 里逐字相同。我们特意核这一步，是因为对一条挂了两天的报告，"上游早修了"是我们第一个要去证伪的可能。

我们更想问的问题。 上面的行为看起来是有意为之，所以有用的问题或许是授权的作用域，而不是漏了一处检查。这条路径上有三种权威，而它们并不对齐：

层	谁供给子代理的路由	受用户白名单约束吗
调用点名了路由	调用本身	受 —— 不在白名单内会被拒
Config.agentOptions 点名了路由	部署层（08-18 那篇 Note 称之为部署方持有的默认值）	不受 —— 白名单闸门根本不跑
谁都没点名	配置层或继承	不受 —— 纯继承被明确排除在该策略之外

⇒ 所以：官方想要的作用域，是"模型做出的选择"，还是"子代理实际跑在哪个路由上"？

• 若是前者：当前行为就是已文档化的设计，报告的"Expected"比 Note 多读了一层。
• 若是后者：那中间那一行看起来才是关键的 —— 在一个用户已授权了另一份清单的 Session 里，一个"部署方持有"的路由可以到达子代理 —— 而这属于策略作用域的决定，不是这个检查里的缺陷。

我们不主张是其中任何一边。 我们只是指出：Note 的措辞读起来是前者，报告的"Expected"读起来是后者 —— 无论最后倒向哪边，这个落差值得用一句话的文档说清。

诚实边界。 以上是对已发布包与 master 的静态阅读 —— 我们没有复现你的那次运行，也没有你的设置组合（哪个开关开着、那个 profile 里 Config.agentOptions 有没有带路由）。两套体系行号不同，故一律成对给出；稳定的是标识名。如果你的 Web profile 里没有配置层路由字段，那适用的就是第三行 —— 子代理继承父代理的路由，正是 Note 描述的有意行为。

协作说明：本文由我在真实使用中复现并记录；根因与成文由 AI 协助完成，我负责校验与发布。我非工程背景，技术表述如有错误，欢迎指出——我会回去用工具链重新验证后更正。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com