[nissa-seru]

codeExecution.enabled takes only true or false, or can be left out, with null counting as left out. create() refuses any other value, and a codeExecution that isn't an object, so a quoted "false" no longer turns code execution on.

!Fixes #473

Problem

On main (e6703634), create() reads config.codeExecution?.enabled by truthiness twice:

• to decide whether validateCodeExecutionConfig runs (src/framework.ts:2303);
• to decide whether the tool is synthesized: codeExecutionConfig is the config when the switch is truthy and null otherwise (:2639), and the code_execution tool and its interpreter are gated on that field (:4291, :14991).

So "enabled": "false", as a JSON config or a ${VAR} substitution can write it, gives agents the code_execution tool and a python interpreter on the host. A falsy non-boolean, such as 0, is read as off, and nothing says so. So is a bare codeExecution: true, whose switch reads as undefined. The type and its doc say the switch is a boolean and the tool is "only synthesized when true" (src/types/framework.ts:44-45).

Changes

• The refusal. validateCodeExecutionConfig refuses an enabled that isn't true, false or null, naming the value's kind rather than the value, as the MCPL server boolean refusals do. A string gets "true or false, unquoted". null counts as not set.
• The parent. A codeExecution that isn't an object, such as a bare true, is refused too, naming its kind.
• When it runs. create() runs the validator whenever codeExecution is given, and the validator checks the other settings only once enabled is true. So a configuration that isn't on still has its other settings left unchecked, as before.
• The gate. The tool is synthesized only for enabled === true.
• kindOf is exported from src/mcpl/transport.ts for the validator's message. The package entry doesn't re-export it.
• Text: the enabled doc says what's refused, and a changelog fragment under Fixed.

What callers will notice

• create() now refuses a codeExecution.enabled such as "false", "true", 0, 1 or an object, with "codeExecution.enabled must be true or false, … not a string" (or the value's kind). Such a config used to start, with code execution on for a truthy value and off for a falsy one.
• It also refuses a codeExecution that isn't an object, such as true, with "codeExecution must be an object, such as { enabled: true }, not a boolean". It used to start with code execution off.
• enabled: true, false, null or left out behave as before.
• Nothing public changes shape: validateCodeExecutionConfig and kindOf aren't exported from the package entry.

What each part is for

• Refusing rather than reading === true alone. Reading only true as on would make "false" off, but "true" off too, without a word. The refusal says at create() which value was misread. It's the rule fix(mcpl): an MCPL server's boolean settings are true or false, and anything else is refused (#379) #451 set for an MCPL server's booleans.
• null as not set. A generated config can write a setting it leaves unset as null, and this keeps such a config working, as fix(mcpl): an MCPL server's boolean settings are true or false, and anything else is refused (#379) #451 does.
• The kind, not the value. A substituted value can be a credential.
• Refusing a codeExecution that isn't an object. Its switch would read as undefined, so it would be off without a word, the same misread one level up.
• Calling the validator whenever codeExecution is given. Called only when the switch is truthy, as on main, it would never see a falsy non-boolean such as 0.
• Checking nothing else when it's off. A configuration that isn't on is never read, so refusing its other settings would only refuse what did no harm before.
• === true at the gate, beside the refusal. With the refusal in front of it, a non-boolean reaches the gate only if the caller changes the config while create() runs, so taking it out alone fails no test. It keeps the gate meaning what the type says.
• Exporting kindOf rather than copying it, so both refusals word a kind the same way.
• The tests.
  • One test runs create() with a quoted "false", a token-like string, 0 and an object as the switch. Another runs it with true, "true" and an array as codeExecution. Each checks the refusal's whole message, so no value can show, and that nothing was left at the store's path.
  • A third checks that a null codeExecution, and contradictory limits beside an enabled that is null, false or left out, each create a framework that doesn't offer code_execution.

Tests

At 2e117acf, on Linux, Node 24.22.0 and Python 3.13.5. The pull request's CI runs the whole suite on Node 20 and 24.

• test/code-execution.test.ts and test/mcpl-config-booleans.test.ts pass 64 and 8 tests.
• With main's four changed source files, 2 of those fail: the two refusal tests, which get no rejection. In that state, a probe that creates a framework with enabled: "false" finds code_execution offered, and a call to it runs python and prints its version.
• Each piece taken back out alone fails a test:
  • the switch's refusal: the switch's refusal test;
  • the parent's refusal: the parent's refusal test;
  • null as not set, or leaving the switch out as not set: the off test;
  • checking nothing else when it's off, taken out or narrowed to enabled === false: the off test, whose off configurations are then refused for their limits;
  • the validator's call put back to main's truthy one: both refusal tests;
  • the call letting a null codeExecution through to the validator: the off test;
  • the call moved to after the store opens: both refusal tests, which find a store left behind.
• The gate's === true, taken out alone, fails no test, as "What each part is for" says (at 8b3acaf3, whose gate is this head's).
• At this head, the same probe's create() rejects with "codeExecution.enabled must be true or false, unquoted, not a string: true gives agents the code_execution tool, …".

Not verified

• No live MCPL server or provider took part, and nothing ran on Windows.

Related

• fix(code-execution): the python runner gets the child allowlist and its own working directory (follow-up to #175) #193, open, also changes validateCodeExecutionConfig, to refuse an inheritEnv that isn't true, false or null, and an env that isn't an object of string values, and exports kindOf, with its own doc and its own answers for null and undefined. So the two conflict in both files. The two validators' refusals are separate checks, and fix(code-execution): the python runner gets the child allowlist and its own working directory (follow-up to #175) #193's kindOf covers every case this change's needs.

Written by Effie-2756 (Claude Opus 5.5) using the Rookery's Pi tooling, on Ada-1017's calls. Naomi-2422 (Claude Opus 5.5) reviewed the change.

[greptile-apps]

Required label not found on this PR.