GkeCodeExecutor sandbox mode is incompatible with current k8s-agent-sandbox

[yamadayuki]

Summary

GkeCodeExecutor(executor_type="sandbox") cannot work with any recent version of k8s-agent-sandbox. The code in _execute_in_sandbox targets the 0.1.x client API, but pyproject.toml declares k8s-agent-sandbox>=0.1.1.post3 with no upper bound — so a fresh pip install "google-adk[extensions]" always produces a broken combination.

I'd like to understand whether sandbox mode is still intended to be supported before deciding how to build on it.

Versions

• google-adk 2.6.0 (also reproduced on 2.4.0; main as of 2026-07-30 has the same code)
• k8s-agent-sandbox 0.5.4 (latest on PyPI)

What the code does

src/google/adk/code_executors/gke_code_executor.py:

def _execute_in_sandbox(self, code: str) -> CodeExecutionResult:
    with SandboxClient(
        template_name=self.sandbox_template,
        gateway_name=self.sandbox_gateway_name,
        namespace=self.namespace,
    ) as sandbox:
        sandbox.write("script.py", code)
        result = sandbox.run("python3 script.py")

Reproduction (no cluster required)

$ pip install "k8s-agent-sandbox==0.5.4"
$ python -c "
from k8s_agent_sandbox import SandboxClient
SandboxClient(template_name='t', gateway_name=None, namespace='default')
"
TypeError: SandboxClient.__init__() got an unexpected keyword argument 'template_name'

Three independent incompatibilities, all verified by introspection on 0.5.4:

	0.1.1.post3 (the declared floor)	0.5.4 (current)
__init__ kwargs	template_name, namespace, gateway_name, …	connection_config, tracer_config, cleanup
context manager	__enter__ / __exit__ present	absent (AsyncSandboxClient has async with)
write / run	sandbox.write() / sandbox.run()	sandbox.files.write() / sandbox.commands.run()
CRD API version	v1alpha1	v1beta1

$ python -c "
import inspect
from k8s_agent_sandbox import SandboxClient
print(inspect.signature(SandboxClient.__init__))
print('__enter__:', hasattr(SandboxClient, '__enter__'))
print('write/run:', hasattr(SandboxClient, 'write'), hasattr(SandboxClient, 'run'))
print([m for m in dir(SandboxClient) if not m.startswith('_')])
"
(self, connection_config=None, tracer_config=None, cleanup=False)
__enter__: False
write/run: False False
['create_sandbox', 'delete_all', 'delete_sandbox', 'get_sandbox',
 'get_sandbox_claim_warmpool_name', 'list_active_sandboxes',
 'list_all_sandboxes', 'sandbox_class']

The current 0.5.x flow looks like this instead:

client = SandboxClient(connection_config=SandboxInClusterConnectionConfig())
sandbox = client.create_sandbox(warmpool="...", namespace="...", shutdown_after_seconds=120)
sandbox.files.write("script.py", code, timeout=60)
result = sandbox.commands.run("python3 script.py", timeout=60)
sandbox.terminate()

Note create_sandbox(warmpool: str, ...) — a SandboxWarmPool is now required, which is a meaningful behavioural change from the 0.1.x template_name model.

Why this seems to have gone unnoticed

• The only prior report, GkeCodeExecutor sandbox mode: ImportError due to wrong module name (agentic_sandbox vs k8s_agent_sandbox) #4883, was an ImportError (agentic_sandbox vs k8s_agent_sandbox) whose repro stops at GkeCodeExecutor(...) construction — it never reaches execute_code, so the deeper mismatch was never hit. fix: update GkeCodeExecutor sandbox import from agentic_sandbox to k8s_agent_sandbox #4884 fixed only the import name, and _execute_in_sandbox hasn't been touched since 2026-03-18.
• The unit tests mock SandboxClient wholesale, so _execute_in_sandbox is never exercised against the real SDK.
• The agent-sandbox repo's own ADK example (examples/code-interpreter-agent-on-adk) does not use GkeCodeExecutor; it wraps SandboxClient as a plain function tool.

Pinning k8s-agent-sandbox==0.1.1.post3 does make the current code work, but 0.1.x talks v1alpha1, which the CRDs now mark deprecated: true / storage: false. That doesn't look like a path worth building on.

Questions

1. Is executor_type="sandbox" still intended to be supported, or is executor_type="job" the recommended path going forward?
2. If it is supported, which k8s-agent-sandbox version range is it validated against? Would adding an upper bound to the extensions extra be appropriate in the meantime, so the broken combination isn't the default install?
3. Would a PR updating _execute_in_sandbox to the 0.5.x API be welcome? If so, some design input would help:
   • create_sandbox now requires a warmpool name — should that become a field on GkeCodeExecutor alongside sandbox_template?
   • which SandboxConnectionConfig should be the default (in-cluster vs gateway vs local tunnel)?
4. Separately: _execute_in_sandbox currently ignores timeout_seconds, cpu_requested / mem_limit, and invocation_context (so there's no equivalent of job mode's invocation-id annotation). Is that intentional — i.e. all of it delegated to the SandboxTemplate — or in scope for the same fix?