GkeCodeExecutor sandbox mode: ImportError due to wrong module name (agentic_sandbox vs k8s_agent_sandbox)

[leslyarun]

Bug Description

GkeCodeExecutor with executor_type="sandbox" fails at instantiation because the code imports from agentic_sandbox import SandboxClient, but the declared dependency k8s-agent-sandbox provides the module as k8s_agent_sandbox.

Steps to Reproduce

pip install google-adk k8s-agent-sandbox kubernetes

from google.adk.code_executors import GkeCodeExecutor

executor = GkeCodeExecutor(
    namespace="agent-sandbox-system",
    executor_type="sandbox",
    sandbox_template="python-code-sandbox",
    sandbox_gateway_name="",
    timeout_seconds=300,
    cpu_limit="2",
    mem_limit="2Gi",
)

Expected Behavior

GkeCodeExecutor should instantiate successfully when k8s-agent-sandbox is installed.

Actual Behavior

ImportError: k8s-agent-sandbox not found. To use Agent Sandbox, please install
google-adk with the extensions extra: pip install "google-adk[extensions]"

Even though k8s-agent-sandbox IS installed. The root cause:

1. gke_code_executor.py:33 does from agentic_sandbox import SandboxClient
2. This fails because k8s-agent-sandbox provides the module as k8s_agent_sandbox, not agentic_sandbox
3. SandboxClient becomes None
4. _check_sandbox_dependency validator raises ImportError on instantiation

Root Cause

The import name doesn't match the package's actual module name:

	Expected by google-adk	Actual in k8s-agent-sandbox
Import	from agentic_sandbox import SandboxClient	from k8s_agent_sandbox import SandboxClient
Module dir	agentic_sandbox/	k8s_agent_sandbox/
top_level.txt	—	k8s_agent_sandbox

Verified on both k8s-agent-sandbox==0.1.1.post3 and 0.2.1 — neither provides an agentic_sandbox module.

Suggested Fix

Change the import in gke_code_executor.py:

# Before
try:
  from agentic_sandbox import SandboxClient
except ImportError:
  SandboxClient = None

# After
try:
  from k8s_agent_sandbox import SandboxClient
except ImportError:
  SandboxClient = None

Workaround

Create a shim module agentic_sandbox/__init__.py on PYTHONPATH:

from k8s_agent_sandbox import SandboxClient
__all__ = ["SandboxClient"]

Environment

• google-adk: 1.27.2
• k8s-agent-sandbox: 0.2.1
• Python: 3.13
• Kubernetes: GKE with Agent Sandbox controller + WarmPool

Related

• PR execute-type param addition in GkeCodeExecutor #4111 (added executor_type="sandbox" support)
• k8s-agent-sandbox package: https://github.com/kubernetes-sigs/agent-sandbox/tree/main/clients/python/agentic-sandbox-client

[leslyarun]

Additional context: the k8s-agent-sandbox package was renamed from agentic_sandbox to k8s_agent_sandbox in kubernetes-sigs/agent-sandbox#322, merged Feb 18, 2026.

The google-adk commit that added from agentic_sandbox import SandboxClient (9c451662, PR #4111) landed March 2, 2026 — 12 days after the rename. So the import was already wrong at the time it was committed.

[raye-deng]

This is a textbook example of a failure mode we see constantly with AI-generated code: the import statement references a plausible-sounding module name that does not actually match the installed package.

In this case, from agentic_sandbox import SandboxClient looks perfectly reasonable — the package was literally renamed from agentic-sandbox to k8s-agent-sandbox at some point, and the code references the old module path. A human reading the import would not immediately flag it. An AI coding assistant generating this import would pick the most "likely" module name from its training data, which may be outdated.

The pattern generalizes: AI tools frequently generate imports referencing package names or module paths that existed at training-data cutoff but have since been renamed, restructured, or deprecated. The code compiles if the dependency is not installed (lazy import with fallback), tests pass if the code path is not exercised, and it only blows up in production when someone actually calls it.

What makes this particularly insidious is that the error message says "please install google-adk with the extensions extra" — which is technically wrong advice, since the package IS installed, just under a different module name. So even the error-handling path misleads.

For anyone dealing with this class of issue at scale: npx @opencodereview/cli scan . --sla L1 — it validates import paths against actual installed package module names as part of the CI pipeline.