feat: ContainerCodeExecutor should support input_files and output_files #5302

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 ignored
• output_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

1. Input files: Use container.put_archive() to copy input_files into the container (e.g., to /tmp/inputs/) before code execution
2. Output files: Use container.get_archive() to retrieve files from a designated output directory (e.g., /tmp/outputs/) after code execution
3. 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 files
• UnsafeLocalCodeExecutor 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+