Quick Start
Enable Tool Bridge on an Agent
Register tools on the agent and enable
code_tools in ExecutionConfig.Why Use Code Mode?
Before code mode, fetching 20 URLs required 20 LLM round-trips and 20 page bodies entering the context window. After code mode, the model emits one short script —best = min(extract_price(fetch(u)) for u in urls) — executed in a single turn. Only the final value returns to the model.
Three wins:
- Fewer LLM round-trips — one turn instead of N
- Less context-window pollution — intermediate results never enter the model
- Lower cost and latency — especially on tool-heavy pipelines
How It Works
Intermediate tool results stay inside the executor and never re-enter the model’s context.When to Use Code Mode
Configuration Options
| Option | Type | Default | Description |
|---|---|---|---|
code_tools | bool | False | When True, model-generated code may call the agent’s registered tools via injected proxies. |
code_tools_allow | Optional[List[str]] | None | Explicit per-run allow-list of tool names callable from code. None or empty = no tools exposed (safe default). |
ExecutionConfig alongside code_execution and code_mode.
Safety
- Opt-in only —
code_tools=Falseby default; no tools are exposed unless you setcode_tools=True. - Explicit allow-list required —
code_tools_allow=None(the default) exposes zero tools. You must name each tool. - Every call passes the approval gate —
require_approval, allow-lists, andPRAISON_AUTO_APPROVEenv var all apply on every invocation. - Approval is not sticky — a single approval does not silently unlock later calls in the same script.
- Disallowed tool →
PermissionError— attempting to call a tool not on the allow-list raisesPermissionError. - Unregistered tool →
NameError— calling a name that isn’t registered raisesNameError. - Reserved name
"tools"→ValueError— you cannot add"tools"to the allow-list; it is always the namespace object. - Imports and dangerous builtins remain blocked — AST + blocklist checks from
execute_codestill apply in code mode. - In-process execution — the subprocess sandbox cannot see the tool registry, so code mode deliberately runs in-process. The
ToolProxystores its registry and allow-list in a closure that sandboxed code cannot reach.
Common Patterns
Map/Reduce Over a URL List
Pipeline: Fetch → Parse → Filter → Summarize
Bare-Name vs Namespaced Calls
Inside the script, tools are callable two ways:Best Practices
Keep the allow-list as small as possible
Keep the allow-list as small as possible
Only list the tools that the script genuinely needs. A smaller allow-list limits the blast radius if the model generates unexpected code.
Don't allow-list tools that mutate external state without approval
Don't allow-list tools that mutate external state without approval
Tools that write to databases, send emails, or delete records should require explicit approval. Configure
require_approval=True or use a webhook approval backend before allow-listing them.Prefer code mode only when intermediate results are bulky or numerous
Prefer code mode only when intermediate results are bulky or numerous
For two or three lightweight tool calls where the model needs to reason about each result, plain tool calling is simpler and easier to debug.
Register helper tools instead of importing libraries in the script
Register helper tools instead of importing libraries in the script
Imports in model-generated code are blocked by AST checks. Pre-register Python functions as tools so the model can call them instead of importing.
Related
Sandbox
Secure isolated environments for code execution — note that subprocess sandboxes cannot see the tool registry.
Approval
Configure tool approval gates that apply on every call in code mode.
Allowed Tools
Environment-level and agent-level tool allow-lists.
Code Agent
AI agents that write and execute Python code using external interpreters.

