What this PR does

When tool-parameter validation fails, the validator retries after coercing values, and the boolean-coercion step used to rewrite any string holding the text true/false into a real boolean, no matter what type the field was declared as. This makes that coercion schema-aware so it only fires for fields whose schema actually accepts a boolean (and does not also accept a string), leaving genuine string arguments untouched.

Why it's needed

Self-hosted / OpenAI-compatible models frequently emit booleans as the strings "true"/"false", so the validator coerces them back on a failed-validation retry. The problem is that the coercion was applied indiscriminately: if a tool call legitimately carried the literal text "true" or "false" in a string argument (an old_string, new_string, content, commit message, search pattern, etc.) and validation happened to fail for an unrelated reason, that string was silently turned into a boolean. The tool then operated on true/false instead of the text the model asked for — a silent, hard-to-debug corruption of the requested operation. The neighbouring fixStringifiedJsonValues helper already consults the schema (via getAcceptedTypes) precisely to avoid this class of over-coercion; the boolean path simply never got the same treatment.

Reviewer Test Plan

How to verify

Run the validator unit tests: cd packages/core && npx vitest run src/utils/schemaValidator.test.ts. All existing boolean-coercion tests still pass (genuine boolean fields, nested objects, case-insensitive True/FALSE, etc.), and new tests cover the regression. To confirm the new tests actually exercise the bug, revert only schemaValidator.ts and re-run: the two new "should not corrupt…" / "should not coerce… also accept string" tests fail, proving the guard is what fixes the corruption.

Evidence (Before & After)

Schema: { old_string: {type: string}, new_string: {type: string}, is_active: {type: boolean} }. Params from the model: { old_string: "true", new_string: "false", is_active: "false" } (note is_active arrives as a string, which triggers the coercion retry).

Before: validation still reports an error and params is mutated to { old_string: true, new_string: false, is_active: false } — the two string arguments are corrupted into booleans.

After: validation returns null and params is { old_string: "true", new_string: "false", is_active: false } — only the boolean-typed field is coerced; the string arguments are preserved.

UI/TUI: N/A (pure validation logic, no user-visible surface).

Tested on

The change is platform-independent (pure JSON-schema logic with no OS-specific code paths); verified locally on Linux with vitest, eslint, prettier --check and tsc --noEmit, and CI exercises macOS/Windows.

Environment (optional)

Unit tests only.

Risk & Scope

• Main risk or tradeoff: the coercion is now narrower — a stringified boolean is only converted for a field whose schema accepts boolean. Fields with no schema information are left untouched (previously they were coerced), which is the safer default and matches fixStringifiedJsonValues.
• Not validated / out of scope: this does not change the separate "stringified JSON" coercion, and is independent of fix: coerce non-string tool params to strings for self-hosted LLMs #2512 (which adds the opposite direction — non-string → string — as a new function and does not touch fixBooleanValues).
• Breaking changes / migration notes: none. Genuine boolean fields (including ["boolean","null"] unions and arrays of booleans) are still coerced exactly as before.

Linked Issues

No existing issue — this is a latent correctness bug found while reviewing the tool-parameter validation path. Happy to open a tracking issue if preferred.

Made with Cursor