bug(config): Settings exposes agent.subagents.default but the core parser discards it
@Kaguya-19 is already working on this.
Since Jul 10, 2026.
- Dominant language
- TypeScript
- Stars
- 4k
- Forks
- 453
- Avg merge
- 12h 30m
- Merged PRs (30d)
- 46
Description
UI-related note: this touches the Settings/UI path and may be lower priority during the ongoing frontend refactor.
Summary
The Settings UI and default config expose agent.subagents.default, but the core config parser drops it as an unknown field. Users can save a default subagent model in the UI, but runtime config does not preserve or consume that setting.
Why it matters
The UI promises a “Default model for subagents on non-router paths.” A user can select a subagent default model and save successfully, but the core parser emits only warnings and returns no effective default model. Runtime then builds subagent settings using only timeoutMs, so the selected model does not affect subagent execution.
Evidence
ui/server/services/pilotdeckConfig.js:62toui/server/services/pilotdeckConfig.js:69includes default configsubagents: { default: 'inherit', params: {} }.ui/src/components/settings/view/tabs/PilotDeckConfigTab.tsx:81typessubagents?: { default?: string; params?: Record<string, unknown> }.ui/src/components/settings/view/tabs/PilotDeckConfigTab.tsx:1223toui/src/components/settings/view/tabs/PilotDeckConfigTab.tsx:1228readsconfig.agent?.subagents?.default.ui/src/components/settings/view/tabs/PilotDeckConfigTab.tsx:1422toui/src/components/settings/view/tabs/PilotDeckConfigTab.tsx:1427writes the selected value toagent.subagents.default.ui/src/i18n/locales/en/settings.json:742toui/src/i18n/locales/en/settings.json:746documents the setting as the subagents default model.src/pilot/config/loadPilotConfig.ts:382tosrc/pilot/config/loadPilotConfig.ts:385parsesagent.subagents.src/pilot/config/loadPilotConfig.ts:392tosrc/pilot/config/loadPilotConfig.ts:400warns on every key excepttimeoutMs, sodefaultandparamsare treated as unknown fields.src/pilot/config/loadPilotConfig.ts:403tosrc/pilot/config/loadPilotConfig.ts:405returns onlytimeoutMs.src/cli/createLocalGateway.ts:1089tosrc/cli/createLocalGateway.ts:1097passes onlyagent.subagents?.timeoutMsinto runtime config.
Validation
Validation level: dynamic config parser reproduction.
Repro approach: load a config containing agent.subagents.default: p/m and agent.subagents.params.temperature.
Key output: loadPilotConfig returned subagents: {} and diagnostics included Unknown agent.subagents field default and Unknown agent.subagents field params, both with warning severity. The fields are not fatal, but they are also not retained for runtime use.
Boundary: this validates the config/parser/runtime path, not a full UI click-through. The UI save path and runtime consumption points are anchored above.
Expected behavior
The product should have one consistent contract. If agent.subagents.default is supported, the parser and runtime should preserve and apply it. If it is not supported, the UI/default config/copy should not expose it as a working setting.
Existing coverage checked
Coverage review searched for agent.subagents.default, parseAgentSubagents, and Unknown agent.subagents field default.
Coverage label: not covered. PR #222 fixes multi-subagent concurrency/detail rendering and related event flow, but does not modify agent.subagents.default parser behavior or this UI/core config drift.
Suggested fix
Confirm the intended product semantics first. If the setting should work, add schema/parser support for agent.subagents.default, preserve it in PilotAgentConfig, and wire it into subagent runtime/model selection. If the setting should not exist, remove it from defaults, Settings UI, provider rename repair, and i18n copy.
Suggested tests
- Supported path: UI/default config with
agent.subagents.defaultsurvivesloadPilotConfigand reaches runtime model selection. - Unsupported path: default config and Settings UI no longer emit
agent.subagents.default. - Parser diagnostics do not silently warn-and-drop a setting that the UI presents as supported.
- Provider rename repair does not maintain stale refs for an unsupported field, or correctly rewrites it if supported.
Submitted with Codex.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.