subagent-codex cannot carry a reasoning effort, though the Codex app-server protocol supports it

[ckanner]

Summary

A session cannot ask for a specific reasoning effort when it delegates to Codex. Neither the tool schema nor the provider config can carry one, so an instruction like "use the Codex subagent with this model and thinking level" is not expressible through the harness — and the model, correctly, works around it.

Observed in a real session (DSH 0.2.0-rc.2): the user asked to delegate to Codex with gpt-6.1-sol at extra-high reasoning. The model read codex exec --help, concluded "I don't control model params through the tool schema", then launched four background codex exec -m gpt-6.1-sol -c model_reasoning_effort=xhigh jobs through bash — bypassing the delegation path entirely (no subagent lifecycle, no list_agents visibility, no structured result handling). The workaround was the only way to honour the request.

Three gates, all verified on master (5badb150, tag dsh-v0.2.1-alpha.1)

1. The tool schema has no effort field.
packages/subagent/tool-subagent/src/index.ts:400 spreads the model-selection parameters — provider, model, reasoning_effort — into the tool schema only when modelSelectionEnabled. For subagent_codex that is never true, so the model sees description and prompt only.

2. modelSelectionSettings cannot be enabled on the Codex row.
packages/subagent/tool-subagent/src/index.ts:341 asserts the chosen provider declares agentOptions, and packages/subagent/subagent-codex/src/index.ts:64 declares NO_START_CAPABILITIES. Setting modelSelectionSettings: true on the Codex row therefore throws while the preset's plugin list mounts:

tool-subagent: provider "codex" does not support child model selection

3. The provider has no config field for it.
packages/subagent/subagent-codex/src/index.ts:36-40 — Config is providerName, model, env, permissionMode, disposeGraceMs. model pins the model; nothing pins the effort.

But the capability is already there

The Codex app-server protocol this provider already speaks accepts both fields:

• ThreadStartParams (27 fields) includes reasoningEffort
• TurnStartParams (25 fields) includes effort

packages/subagent/subagent-codex/src/wire.ts:289 sends { cwd, ephemeral, model?, ...permission } to thread/start, and :321 sends { threadId, input } to turn/start. The field exists on the wire; the provider simply never populates it.

DSH also already treats the concept as first class — agentOptions.reasoningEffort is a typed field at tool-subagent/src/index.ts:116.

Suggested fix

Any of these closes it; the first is the smallest:

1. subagent-codex: add reasoningEffort to Config and forward it on thread/start (and/or effort on turn/start).
2. subagent-codex: declare agentOptions: true and map request.agentOptions.reasoningEffort onto the protocol field. This also makes modelSelectionSettings legal on the Codex row, so a model can pass it per call.
3. tool-subagent: allow a configured reasoningEffort for providers that do not support agentOptions.

Related: a failed preset mount is silent

When a row in a preset's plugins list throws during mount, the preset disappears from the picker and nothing surfaces the reason. In our case both self-defined presets vanished at once after a restart, and the only evidence was a plugin log. A surfaced error — in the picker, or in the session's runtime context — would have saved a long debugging session.

Environment

• DSH 0.2.0-rc.2 (installed app); master @ 5badb150 / dsh-v0.2.1-alpha.1 checked for the same code path
• macOS 27.0.1, arm64
• Codex CLI 0.160.1 (@openai/codex)
• ~/.codex/config.toml carries model = "gpt-6.1-sol", model_reasoning_effort = "medium"

I understand external PRs are not being accepted right now, so this is a report rather than a patch offer — happy to share the exact diff or test a fix if that would help.

[ckanner]

Additional field evidence from a second session, which confirms the gap from the caller's side.

A model asked to delegate with a specific model did the obvious thing — it passed model to the tool:

await tools.subagent_codex({
  description: "model probe",
  prompt: "...",
  run_in_background: true,
  model: "gpt-6-astra",
})

and got a clear, immediate refusal naming the exact condition:

ToolCallError: child model selection is disabled for this tool instance

So the surface is honest — it says disabled, not ignored — and the model then read codex exec --help and prepared a shell fallback, which is the behaviour the harness would rather own.

Worth noting the rest of the delegation path is healthy in the same session: six subagent_codex calls ran as background jobs and their results were collected with job_output. The only thing that cannot be expressed is the model (and, per the report, the reasoning effort).

It also means the fix is purely additive: no caller changes, no prompt changes — enabling (2) from the report would make the probe above succeed as written.

[ckanner]

A second, separate defect found while working around the first one. I am reporting the reproduction and the evidence; the cause is not established.

Two delegation rows, one of them with an external provider

A preset contains the usual tool-subagent rows, and a second row for an external (non-spawn) provider:

- id: tool-subagent            # registers fine
  name: '@deepseek-ai/dsh-tool-subagent'
  config:
    provider: spawn
    toolName: subagent
    modelSelectionSettings: true
    backgroundMode: continuable

- id: tool-subagent-codex      # never registers a tool
  name: '@deepseek-ai/dsh-tool-subagent'
  config:
    provider: codex-effort
    toolName: subagent_codex
    modelSelectionSettings: true
    backgroundMode: one-shot
    maxDepth: provider-managed

Observed

subagent_codex is absent from request/header.tools in every session of that preset. subagent, subagent_fork and list_subagent_models are all present. No error is surfaced anywhere: not in the session log, not in the unified log, and the preset does not show as failed.

What is ruled out

• Not the provider. ctx.subagents.getProvider('codex-effort') returns the provider at session time (logged from the plugin), and it declares capabilities.agentOptions: true.
• Not the row shape. The identical row with modelSelectionSettings omitted registers its tool normally. The only difference between the working and failing row is that flag.
• Not a tool-name collision. registerListSubagentModels does register a fixed name (list_subagent_models) unconditionally, which looked like the cause, but giving the Codex row its own cordis:group — its own scope, since the registry reports "already registered in this scope" — changed nothing.
• Not maxDepth. The official Codex row in the shipped presets carries the same maxDepth: provider-managed and mounts.

Why it is silent

Enabling the flag takes install() down the ctx.get('subagentModelSelection') path and then mount(provider), whose only throw is modelSelectionCapable && !capabilities.agentOptions. That condition should hold for this provider, so either the provider value the row receives is not the one registered, or the failure is upstream of mount. Either way the row dies without a tool and without a message, which is the part that costs the most time.

Workaround

The plugin now registers its own delegation tool on agent/created into the Agent's own context, the way dsh-plugin-lcu registers its tools. That path needs no preset row and no modelSelectionSettings, and the delegation succeeds with a per-call model and reasoning effort. It works, but it means a plugin cannot use the harness's own delegation tool for an external provider — which is presumably what the flag is for.