The streaming requirement for confirm_code_execution now fires only when a
local code-execution tool (python/terminal) could actually run, so a
non-streaming request that enables only non-code tools (web_search,
render_html, ...) is no longer rejected. This matches the documented behavior
that confirm_code_execution leaves non-code tools unaffected.
- Per-handler (GGUF and safetensors): gate on the resolved tool list
intersecting python/terminal.
- Pre-switch: gate on a payload-level predicate that mirrors
_select_request_tools (built-ins off unless the tool loop is enabled; an
explicit enabled_tools filter must list python/terminal).
- External-provider and Anthropic server-tool rejections stay broad: the local
confirm gate cannot apply there at all.
Tests: predicate coverage for both the resolved and payload-level checks.
Review follow-up: validate confirm_code_execution at the same request-lifecycle
points as confirm_tool_calls so it can never be silently accepted where the
confirm gate cannot apply.
- External providers: reject confirm_code_execution (code_execution runs
provider-side, so the local confirm gate cannot intercept it) instead of
giving the caller a false approval guarantee.
- Pre-switch: reject a non-stream confirm_code_execution local tool request
before automatic model loading, so an invalid shape does not evict the
resident model only to 400 after the swap.
- Drop the code-execution tool scoping on the per-request stream requirement so
it mirrors confirm_tool_calls exactly (removes _enables_code_execution_tool).
Tests: provider rejection for confirm_code_execution; existing streaming
requirement + gate tests still pass.
Adds an opt-in request field, confirm_code_execution, that routes local
code-execution tool calls (python, terminal) through the existing
confirmation gate while other tools (web_search, render_html, MCP, ...)
continue to run without a prompt.
This lets a caller require approval for code execution specifically,
without the friction of confirm_tool_calls prompting on every tool. It is
independent of confirm_tool_calls, defaults off (no change to existing
behavior), requires stream=true when a code-execution tool is enabled
(same as confirm_tool_calls), and bypass_permissions still takes
precedence.
The tool-call parser and tool detection are unchanged, so no tool-calling
behavior is affected when the flag is off.
- models: new confirm_code_execution field on ChatCompletionRequest
- tools: CODE_EXECUTION_TOOL_NAMES = {python, terminal}
- safetensors and gguf loops: needs_confirm also fires for code-execution
tools when confirm_code_execution is set (bypass still wins)
- routes: thread the flag to both local loops; require streaming when a
code-execution tool is enabled
- tests: loop-level gate behavior, the scoping predicate, and the route
streaming requirement for both backends
