Summary
When a toolset uses ref: to point to a top-level mcps: definition that itself has a remote.url, the working_dir field set on the referencing toolset is silently discarded at runtime.
Root cause
Validation (validate.go) correctly rejects working_dir on a toolset whose remote field is set directly. However, resolveMCPDefinitions / applyMCPDefaults runs after validation, merging the remote definition into the toolset. So this config slips past the rule:
mcps:
some_remote_def:
remote: { url: https://... }
agents:
root:
toolsets:
- type: mcp
ref: some_remote_def
working_dir: ./foo # passes validation, silently no-ops at runtimeFix options
- Re-invoke validation after
applyMCPDefaults / resolveMCPDefinitions.
- Or: add a check in the
remote.URL branch of createMCPTool that returns an explicit error if toolset.WorkingDir != "".
Impact
Silent no-op — working_dir appears to be accepted but has no effect. No crash.
Related
Introduced alongside #2460. Identified during code review (finding F1).
Summary
When a toolset uses
ref:to point to a top-levelmcps:definition that itself has aremote.url, theworking_dirfield set on the referencing toolset is silently discarded at runtime.Root cause
Validation (
validate.go) correctly rejectsworking_diron a toolset whoseremotefield is set directly. However,resolveMCPDefinitions/applyMCPDefaultsruns after validation, merging the remote definition into the toolset. So this config slips past the rule:Fix options
applyMCPDefaults/resolveMCPDefinitions.remote.URLbranch ofcreateMCPToolthat returns an explicit error iftoolset.WorkingDir != "".Impact
Silent no-op —
working_dirappears to be accepted but has no effect. No crash.Related
Introduced alongside #2460. Identified during code review (finding F1).