fix(schema): accept tools.codeMode at agent-entry scope (#83388)#83394
fix(schema): accept tools.codeMode at agent-entry scope (#83388)#83394hclsys wants to merge 1 commit into
Conversation
docs/reference/code-mode.md describes 'tools.codeMode.enabled: true' as
settable on 'the agent or runtime config'. The top-level ToolsSchema
already accepts codeMode, but AgentToolsSchema is .strict() and didn't
include the key, so gateway startup rejected the documented per-agent
shape with 'agents.list.0.tools: Unrecognized key: "codeMode"'.
Add 'codeMode: CodeModeSchema' to AgentToolsSchema. The schema is the
same one consumed at the top level, so the boolean shorthand and the
full object form (enabled/runtime/timeoutMs/languages/...) all behave
identically at the per-agent scope. strict() is preserved on the inner
schema; unknown nested keys still reject.
Adds 1 regression case in zod-schema.agent-defaults.test.ts covering:
- per-agent { codeMode: { enabled: true } } shape accepts
- boolean codeMode: true shape accepts
- full options object accepts
- unknown nested key still rejected (strict() preserved)
|
Codex review: needs real behavior proof before merge. Workflow note: Future ClawSweeper reviews update this same comment in place. How this review workflow works
Summary Reproducibility: yes. Current-main source shows the documented PR rating Rank-up moves:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. Real behavior proof Risk before merge
Maintainer choices:
Next step before merge Security Review findings
Review detailsBest possible solution: Revise the PR to make Do we have a high-confidence way to reproduce the issue? Yes. Current-main source shows the documented Is this the best way to solve the issue? No. Accepting the key in the schema is necessary but not sufficient because the selected agent's override is not used by code-mode activation or the OpenAI payload guard. Full review comments:
Overall correctness: patch is incorrect Security concerns:
Acceptance criteria:
What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against cd15ce35a0ee. |
Fixes #83388.
docs/reference/code-mode.mddescribestools.codeMode.enabled: trueas settable at "the agent or runtime config", butAgentToolsSchemainsrc/config/zod-schema.agent-runtime.tsis.strict()and didn't includecodeMode. Only the top-levelToolsSchemaaccepted it. Gateway startup rejected the documented per-agent shape withagents.list.0.tools: Unrecognized key: "codeMode".This patch adds
codeMode: CodeModeSchematoAgentToolsSchema, mirroring the top-level schema.CodeModeSchemaalready supports the boolean shorthand and the full options object (enabled/runtime/mode/languages/timeoutMs/memoryLimitBytes/...).strict()is preserved on the inner schema, so unknown nested keys still reject.Per-agent enablement enables the testing/rollout pattern the issue requests: turn on code mode for a single agent without forcing fleet-wide behavior change.
Changes
src/config/zod-schema.agent-runtime.ts: addcodeMode: CodeModeSchematoAgentToolsSchema. 5-line comment referencing code-mode: AgentToolsSchema rejects "codeMode" key but docs say agent-level config works #83388.src/config/zod-schema.agent-defaults.test.ts: 1 new regression case covering boolean shorthand,{enabled: true}shape, full options object, and a negative-control (unknown nested key still rejected).Real behavior proof
Behavior or issue addressed: Gateway rejected the documented per-agent shape
{ id: "test-agent", tools: { codeMode: { enabled: true } } }withUnrecognized key: "codeMode".Real environment tested: Local Node 22.x with the actual
zod/v4package from a sibling scout checkout (/tmp/openclaw_scout/node_modules/zod/v4/index.cjs). Probe at/tmp/probe_83388.mjsrebuilds the relevant pieces (CodeModeSchemaunion of boolean + strict object, an OLDAgentToolsSchema-shaped strict object without codeMode, and a NEW one with it) and parses 5 inputs against both.Exact steps or command run after this patch:
node /tmp/probe_83388.mjsEvidence after fix:
Observed result after fix:
AgentEntrySchema.safeParse({ id: "...", tools: { codeMode: { enabled: true } } })now returnssuccess: true. The boolean shorthandcodeMode: trueand the full options object are also accepted (mirroring the top-level shape). Unknown nested keys still reject becauseCodeModeSchema's inner object is.strict()— this is the negative-control assertion.What was not tested: End-to-end gateway restart against a real config file with a per-agent
codeModeblock. The new vitest case covers the schema-level public contract (AgentEntrySchema.safeParse); the probe covers the zod-package-level behavior in isolation; the gateway config-validation path consumes the sameAgentEntrySchemaso this fix transitively unblocks the startup path the issue describes.Audit (per CLAUDE rules)
CodeModeSchemadeclared at line 590 of the same file (the schema the top-levelToolsSchemaalready uses). No new schema definition. PASSAgentToolsSchemais file-local (noexport). Consumed at exactly one site:AgentEntrySchemaat line 1009. Adding an optional key doesn't break existing consumers — they continue to omitcodeMode. PASSAgentToolsSchema/codeModeschema as of branch SHA. PASS