Summary
ContainerCodeExecutor currently ignores CodeExecutionInput.input_files and always returns an empty output_files list. This makes it impossible to pass files into the container or retrieve generated files from it.
Current Behavior
In container_code_executor.py, execute_code():
exec_result = self._container.exec_run(
['python3', '-c', code_execution_input.code],
demux=True,
)
return CodeExecutionResult(
stdout=output,
stderr=error,
output_files=[], # Always empty
)
code_execution_input.input_files is completely ignoredoutput_files is always an empty list- No Docker volume mounts are configured
optimize_data_file is forced to False (frozen)
Expected Behavior
ContainerCodeExecutor should support file I/O through the existing File / CodeExecutionInput / CodeExecutionResult data structures, which already support binary content (content: str | bytes).
Suggested approach
- Input files: Use
container.put_archive() to copy input_files into the container (e.g., to /tmp/inputs/) before code execution
- Output files: Use
container.get_archive() to retrieve files from a designated output directory (e.g., /tmp/outputs/) after code execution
- Alternatively, support a
volumes parameter for Docker bind mounts
Use Case
We use an LLM agent system where a supervisor agent downloads files (e.g., Excel, CSV) to /tmp/ and needs to pass them to a code execution agent for processing (e.g., data transformation with openpyxl/pandas).
BuiltInCodeExecutor runs on the Gemini server, so it cannot access local filesUnsafeLocalCodeExecutor can access local files but is not safe for production (unrestricted exec() with access to credentials, env vars, etc.)ContainerCodeExecutor would be the ideal middle ground — isolated execution with file access — but file I/O is not implemented
Impact
Without file I/O support, ContainerCodeExecutor is limited to pure computation tasks (math, data generation). File processing workflows must either:
- Use
BuiltInCodeExecutor (no local file access) and pass all data through LLM context (slow for large data)
- Use
UnsafeLocalCodeExecutor (security risk in production)
Environment
- ADK version: google-cloud-aiplatform[adk] 1.100.0
- Python: 3.12+
Summary
ContainerCodeExecutorcurrently ignoresCodeExecutionInput.input_filesand always returns an emptyoutput_fileslist. This makes it impossible to pass files into the container or retrieve generated files from it.Current Behavior
In
container_code_executor.py,execute_code():code_execution_input.input_filesis completely ignoredoutput_filesis always an empty listoptimize_data_fileis forced toFalse(frozen)Expected Behavior
ContainerCodeExecutorshould support file I/O through the existingFile/CodeExecutionInput/CodeExecutionResultdata structures, which already support binary content (content: str | bytes).Suggested approach
container.put_archive()to copyinput_filesinto the container (e.g., to/tmp/inputs/) before code executioncontainer.get_archive()to retrieve files from a designated output directory (e.g.,/tmp/outputs/) after code executionvolumesparameter for Docker bind mountsUse Case
We use an LLM agent system where a supervisor agent downloads files (e.g., Excel, CSV) to
/tmp/and needs to pass them to a code execution agent for processing (e.g., data transformation with openpyxl/pandas).BuiltInCodeExecutorruns on the Gemini server, so it cannot access local filesUnsafeLocalCodeExecutorcan access local files but is not safe for production (unrestrictedexec()with access to credentials, env vars, etc.)ContainerCodeExecutorwould be the ideal middle ground — isolated execution with file access — but file I/O is not implementedImpact
Without file I/O support,
ContainerCodeExecutoris limited to pure computation tasks (math, data generation). File processing workflows must either:BuiltInCodeExecutor(no local file access) and pass all data through LLM context (slow for large data)UnsafeLocalCodeExecutor(security risk in production)Environment