subagent-model-selection-settings: allowedModels 改动对运行中的 Session 不生效，报错也无补救提示 / changes do not apply to a running Session, error gives no remedy

[Matthew-Laplace]

现象

subagent-model-selection-settings 里 allowedModels 的改动对正在运行的 Session 不生效，而且报错信息没有给出可操作的补救方式。

复现（本机 DSH Desktop，profile desktop）：

1. 会话启动时配置为：

   - id: subagent-model-selection-settings
     config:
       enabled: true
       allowedModels:
         - provider: openai-codex
           model: gpt-6.1-sol

2. 在同一会话运行期间，把配置改成（加了第二个模型）：

   allowedModels:
     - provider: openai-codex
       model: gpt-6.1-sol
     - provider: openai-codex
       model: gpt-6-astra

3. 调用 subagent，provider: openai-codex、model: gpt-6-astra：

Error: child LLM route "openai-codex/gpt-6-astra" is not allowed for this Session

改回、再改、反复调用都一样。该模型本身在 provider 目录里是存在的（llm-openai-codex 的 models 列表含 gpt-6-astra），所以不是模型 id 写错。

期望

三选一即可：

• A：改动即时生效（每次调用重新读一次设置），或
• B：报错里明确说明「本 Session 的白名单在会话组装时已采样，需新建会话才能生效」，或
• C：提供查看当前 Session 生效白名单的手段（例如让 list_subagent_models 反映 Session 级的 effective 白名单）

现状是：设置静默不生效，报错只说 "not allowed for this Session"，用户无法区分「模型 id 写错了」「provider 不允许」「需要开新会话」。

影响

• 用户改了配置却看不到任何提示，只能靠猜；排查成本高。
• 会话白名单对用户不可见，list_subagent_models 返回的是 provider 目录而不是 Session 生效集合，两者不一致会误导。
• 无法在不重开会话的前提下放行新模型。

环境

• DSH Desktop（macOS 26.6），profile desktop
• 设置项 id：subagent-model-selection-settings
• 相关包：@deepseek-ai/dsh-tool-subagent

说明

我理解这可能是有意设计——@deepseek-ai/dsh-tool-subagent 的 README 提到策略在会话组装时采样、"unchanged by later settings edits"。这个取舍本身可以理解（避免在途会话权限漂移），但当前的失败模式（静默无效 + 无补救提示）建议至少按上面 B 改一下报错文案。

---

English

Symptom

Changes to allowedModels in subagent-model-selection-settings have no effect on a running Session, and the error offers no remedy.

Reproduction (local DSH Desktop, profile desktop):

1. Session starts with allowedModels: [openai-codex/gpt-6.1-sol].
2. While that session is running, the profile config is edited to add openai-codex/gpt-6-astra.
3. Calling subagent with provider: openai-codex, model: gpt-6-astra fails:

Error: child LLM route "openai-codex/gpt-6-astra" is not allowed for this Session

Re-editing and retrying makes no difference. The model itself is present in the provider catalog (llm-openai-codex.models includes gpt-6-astra), so this is not a typo in the model id.

Expected

Any one of:

• A — the change applies immediately (settings re-read per call), or
• B — the error states that the Session allowlist was sampled at session assembly and a new session is required, or
• C — a way to inspect the Session's effective allowlist (e.g. list_subagent_models reflecting the session-level effective set)

Today the setting silently does not apply, and the message does not distinguish "wrong model id" from "provider not allowed" from "new session required".

Impact

• A config edit produces no feedback; users can only guess.
• The session allowlist is invisible, and list_subagent_models reports the provider catalog rather than the effective session set, so the two disagree.
• No way to allow a new model without restarting the session.

Environment

• DSH Desktop on macOS 26.6, profile desktop
• Settings id: subagent-model-selection-settings
• Package: @deepseek-ai/dsh-tool-subagent

Note

This may well be intentional: the @deepseek-ai/dsh-tool-subagent README says the policy is sampled at session assembly and is "unchanged by later settings edits". That trade-off is understandable (it avoids mid-session permission drift). The request is mainly about the failure mode: at minimum, option B in the error text.

[slyyr]

The first thing I'd check is whether the session's model allowlist is captured when the session starts or read again for every subagent invocation.

If the allowlist is intentionally captured during session initialization, editing the configuration afterward won't necessarily affect the existing session. In that case, starting a new session with the updated configuration is a useful diagnostic step.

I'd test the following:

1. Configure the session with only the first model allowed.
2. Start a new session and confirm that the first model works.
3. Add the second model to the configuration.
4. Try the second model in the existing session.
5. Start a fresh session and repeat the test.

If the second model works only in the fresh session, that supports the session-initialization explanation.

For the longer-term fix, the error message could explicitly state that the allowlist was captured when the session started and recommend creating a new session. A diagnostic command showing the effective session-level allowlist would also make this easier to troubleshoot.

I would verify this against the implementation and documentation before treating it as the confirmed root cause.

[idrivehtbusiness]

I think the behavior itself is probably intentional, but the error message is missing an important piece of context.

If allowedModels is captured when a session starts, updating the profile configuration won't change the permissions of an existing session. That's generally a reasonable security boundary: a running session shouldn't silently gain new capabilities because a configuration file changed.

For your current setup, I'd save the configuration and start a new session. That should load the updated allowlist. If the new session still rejects the model, then I'd investigate the resolved profile and provider configuration.

For the implementation, I'd keep the session-level allowlist immutable and improve the diagnostics rather than hot-reloading permissions.

A useful error would distinguish three cases:

• The model doesn't exist in the provider catalog.
• The model exists but isn't allowed by the active configuration.
• The model is configured now, but the current session was created with an older allowlist.

The third case could return something like:

Model is available in your current settings but isn't permitted in this session. Start a new session to apply the updated model permissions.

I'd also expose the session's effective model list separately from the global provider catalog. Otherwise, users are comparing two different sources of truth without realizing it.

For regression coverage, I'd test this exact sequence: start with model A allowed, add model B while the session is running, verify that B remains blocked in the existing session with a useful explanation, then verify that B works in a newly created session.

That would preserve the existing security behavior while making the failure much easier to understand.