AgentEngineSandboxCodeExecutor incompatible with Gemini 2.x models (MALFORMED_FUNCTION_CALL)

Description

AgentEngineSandboxCodeExecutor does not work with any Gemini 2.x model (gemini-2.5-pro, gemini-2.5-flash, gemini-2.0-flash). All models produce MALFORMED_FUNCTION_CALL errors when attempting code execution.

Root Cause

Gemini 2.x models always emit code as executable_code parts (native code execution format). However, the Gemini API rejects these parts with MALFORMED_FUNCTION_CALL because code_execution is not included in the tools configuration.

AgentEngineSandboxCodeExecutor expects the model to output code in markdown blocks (```python), which it can then parse and route to the Agent Engine sandbox. But Gemini 2.x models never use markdown blocks — they always use the native format.

Meanwhile, BuiltInCodeExecutor works correctly because it adds types.Tool(code_execution=types.ToolCodeExecution()) to the model's tool config, allowing the model to emit executable_code parts that the API accepts.

Steps to Reproduce

Create an agent with AgentEngineSandboxCodeExecutor and any Gemini 2.x model
Deploy to Agent Engine
Ask the agent to execute Python code (e.g., "Use Python code execution to compute 7 * 8 + 3 ** 4")
Response returns MALFORMED_FUNCTION_CALL error

Expected Behavior

AgentEngineSandboxCodeExecutor should add code_execution to the model's tool config (like BuiltInCodeExecutor does), then intercept the resulting executable_code parts and route them to the Agent Engine sandbox instead of letting the model execute them natively.

Note: CodeExecutionUtils.extract_code_and_truncate_content in ADK 1.29.0 already handles executable_code parts correctly — it just never gets a chance to run because the API rejects the model's response before ADK processes it.

Environment

ADK version: 1.28.1 and 1.29.0
Models tested: gemini-2.5-pro, gemini-2.5-flash, gemini-2.0-flash
Platform: Agent Engine (Vertex AI)

@ivanmkc

Hello @ivanmkc, thank you for providing these details. To help us fully understand the issue, could you please share a minimal reproducible example? This will allow us to recreate the problem exactly as you are experiencing it. Thank you!

@ivanmkc

Hello @ivanmkc, thank you for raising this issue. I spent some time reproducing the bug to better understand what’s happening under the hood, and I can confirm there is a structural conflict between the 2.x models and the sandbox executor.

Environment

To ensure reproducibility, here is the environment used:

Google ADK Versions: 1.28.1, 1.29.0
Python Version: 3.14
Vertex AI Location: us-central1
Models Tested: gemini-2.5-flash-lite, gemini-2.5-flash, gemini-2.5-pro

Minimal Reproducible Example

1. Vertex AI Setup & Sandbox Deployment

import os
import vertexai
from vertexai import types

# Initialize Vertex AI
GOOGLE_CLOUD_PROJECT = os.getenv("GOOGLE_CLOUD_PROJECT")
GOOGLE_CLOUD_LOCATION = os.getenv("GOOGLE_CLOUD_LOCATION", "us-central1")

vertexai.init(
    project=GOOGLE_CLOUD_PROJECT,
    location=GOOGLE_CLOUD_LOCATION,
)

client = vertexai.Client(
    project=GOOGLE_CLOUD_PROJECT,
    location=GOOGLE_CLOUD_LOCATION,
)

# Deploy Agent Engine & Sandbox
agent_engine = client.agent_engines.create(
    config={
        "display_name": "issue_5315_repro_agent_engine",
        "staging_bucket": os.getenv("STAGING_BUCKET"),
    }
)

sandbox = client.agent_engines.sandboxes.create(
    name=agent_engine.api_resource.name,
    config=types.CreateAgentEngineSandboxConfig(
        display_name="issue_5315_repro_sandbox"
    ),
    spec={
        "code_execution_environment": {
            "code_language": "LANGUAGE_PYTHON"
        }
    },
)

sandbox_resource_name = sandbox.response.name

2. Agent Creation & Runner Execution

from google.adk.agents import LlmAgent
from google.adk.artifacts import InMemoryArtifactService
from google.adk.code_executors.agent_engine_sandbox_code_executor import AgentEngineSandboxCodeExecutor
from google.adk.runners import Runner
from google.adk.sessions import InMemorySessionService
from google.genai import types as genai_types

agent = LlmAgent(
    model="gemini-2.5-pro",
    name="issue_5315_repro_agent",
    instruction=base_system_instruction() + negative_prompting,
    generate_content_config=genai_types.GenerateContentConfig(temperature=0),
    code_executor=AgentEngineSandboxCodeExecutor(
        sandbox_resource_name=sandbox_resource_name
    ),
)

session_service = InMemorySessionService()
await session_service.create_session(
    app_name="app",
    user_id="user1",
    session_id="session1",
)

runner = Runner(
    agent=agent,
    app_name="app",
    session_service=session_service,
    artifact_service=InMemoryArtifactService(),
)

query = "Use Python code execution to compute 7 * 8 + 3 ** 4"
message = genai_types.Content(
    role="user",
    parts=[genai_types.Part(text=query)],
)

async for event in runner.run_async(
    user_id="user1",
    session_id="session1",
    new_message=message,
):
    print(event)

Findings

Interestingly, I did not encounter the exact MALFORMED_FUNCTION_CALL error mentioned in the original report. Instead, I consistently observed an UNEXPECTED_TOOL_CALL error.

Hypothesis

The discrepancy likely comes from tool configuration differences:

If other tools are registered, the model may try to route execution through them, leading to MALFORMED_FUNCTION_CALL.
With no tools registered (my setup), the model hallucinated a tool call (e.g., print(...)), resulting in UNEXPECTED_TOOL_CALL.

Both errors point to the same root issue.

Model Behavior

gemini-2.5-flash: Often executed correctly using the sandbox
gemini-2.5-flash-lite: Mixed behavior; improved with stricter instructions
gemini-2.5-pro: Consistently failed with UNEXPECTED_TOOL_CALL

Event Logs

Success Case

When the model correctly used the sandbox, it produced a native executable_code part:

{
  "executable_code": {
    "code": "print(7 * 8 + 3 ** 4)",
    "language": "PYTHON",
    "id": null
  }
}

Failure Case

When the model failed, it hallucinated a tool call instead of using the sandbox:

{
  "finish_reason": "UNEXPECTED_TOOL_CALL",
  "error_code": "UNEXPECTED_TOOL_CALL",
  "error_message": "Unexpected tool call: print(7 * 8 + 3 ** 4)"
}

System Instructions

To rule out prompting issues, I based the instructions on the official ADK documentation and later added aggressive negative prompting.

def base_system_instruction():
    return """
    # Guidelines

    **Objective:** Assist the user in achieving their code execution goals with emphasis on correctness, safe execution, and minimal assumptions.

    **Code Execution:** All code snippets will be executed within the sandbox environment.

    **Output Visibility:** Always print outputs to verify correctness.

    Example:
    ```python
    result = 7 * 8 + 3 ** 4
    print(f'{result=}')
    ```
    """

negative_prompting = """
CRITICAL INSTRUCTION:
For ALL math, calculations, and Python execution tasks, you MUST use the native sandbox.

DO NOT use standard tools or function calls to execute code.
"""

Observations

Using the official ADK-style instructions improved behavior for gemini-2.5-flash-lite.
Even with aggressive negative prompting, gemini-2.5-pro continued to fail.

Additional Experiment

To validate the hypothesis, I introduced a dummy tool (print_code) that intentionally returned incorrect results.

Result:
All models, including gemini-2.5-flash, preferred the custom tool over the sandbox, despite explicit instructions.

This strongly suggests that tool selection is prioritized over native sandbox execution.

Conclusion

The agent strongly prioritizes tool usage when a tool registry is present. Without an explicitly defined code execution tool, it:

Hallucinates tool calls, or
Misuses existing tools

This leads to errors like UNEXPECTED_TOOL_CALL or MALFORMED_FUNCTION_CALL.

A robust fix, as @ivanmkc mentioned in this issue report, would be for AgentEngineSandboxCodeExecutor to automatically inject the code_execution capability into the tool configuration, similar to how BuiltInCodeExecutor behaves.

@sanketpatil06
If this aligns with the ADK team’s direction, I’d be happy to open a PR to implement this fix.

@JesserHamdaoui

Hi @JesserHamdaoui , Thanks for providing the reproduction script.
We tested your code and observed the exact same behaviour. In our case it worked perfectly fine with both the gemini-2.5-flash and gemini-2.5-flash-lite models. However, when using the gemini-2.5-pro model, We encountered the exact same error that you reported.
We would absolutely welcome a PR from you to address this. Looking forward to your contribution.

@ivanmkc

Hi @ivanmkc, thank you for reporting this issue!

This has been resolved by PR #5499 and merged into the main branch in commit 8aafa4e.

We are closing this issue as resolved. If you find that the issue persists on the latest ADK release or if this was closed in error, please feel free to reopen it or leave a comment! Thank you again for your contribution.

Are you satisfied with the resolution of your issue?
Yes
No

Navigation Menu

Repository navigation

AgentEngineSandboxCodeExecutor incompatible with Gemini 2.x models (MALFORMED_FUNCTION_CALL) #5315

Description

Root Cause

Steps to Reproduce

Expected Behavior

Environment

Environment

Minimal Reproducible Example

1. Vertex AI Setup & Sandbox Deployment

2. Agent Creation & Runner Execution

Findings

Hypothesis

Model Behavior

Event Logs

Success Case

Failure Case

System Instructions

Observations

Additional Experiment

Conclusion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

AgentEngineSandboxCodeExecutor incompatible with Gemini 2.x models (MALFORMED_FUNCTION_CALL) #5315

Description

Description

Root Cause

Steps to Reproduce

Expected Behavior

Environment

Activity

sanketpatil06 commented on Apr 15, 2026

JesserHamdaoui commented on Apr 20, 2026

Environment

Minimal Reproducible Example

1. Vertex AI Setup & Sandbox Deployment

2. Agent Creation & Runner Execution

Findings

Hypothesis

Model Behavior

Event Logs

Success Case

Failure Case

System Instructions

Observations

Additional Experiment

Conclusion

sanketpatil06 commented on Apr 24, 2026

DeanChensj commented on Oct 14, 2026

github-actions commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions