Cross-invocation code-execution capability bleed via shared LlmAgent mutation

Summary

Before commit f8282dafd3bc63476b76af31d1df3abdad6370fa, an invocation-scoped CFC setting could permanently mutate a shared LlmAgent instance.

When one invocation used RunConfig(support_cfc=True), Runner._new_invocation_context() assigned:

cfc_agent.code_executor = BuiltInCodeExecutor()

If the same long-lived Runner / Agent instance was then reused for another session or request with support_cfc=False, the later invocation could still receive the built-in code_execution capability.

This is a cross-invocation capability/policy bleed: a capability enabled for one invocation persisted into a different invocation that explicitly did not request it.

Affected version

• Reproduced on the direct parent of the fix: 43b73e4f
• The released v2.9.1 source contains the vulnerable assignment in src/google/adk/runners.py
• Fix: https://github.com/google/adk-python/commit/f8282dafd3bc63476b76af31d1df3abdad6370fa

Minimal reproduction

The reproduction only needs local ADK objects; no Gemini call, Google API, or external service is required.

1. Create one Agent with code_executor=None.
2. Create one InMemoryRunner using that Agent.
3. Create independent session A and session B.
4. Build invocation A with RunConfig(support_cfc=True).
5. Run the code-execution request processor for A.
6. Build invocation B with RunConfig(support_cfc=False) using the same Agent.
7. Run the same request processor for B.

Expected

Invocation B should not receive BuiltInCodeExecutor, because CFC is disabled for B.

Pre-fix behavior

Invocation B still sees the built-in code-execution capability because invocation A mutated persistent shared Agent state.

Root cause

RunConfig.support_cfc is invocation-scoped, while LlmAgent.code_executor is persistent shared object state.

The pre-fix Runner converted an invocation-scoped decision into a permanent mutation of the shared Agent. Later invocations therefore observed a capability they did not request.

Security / isolation impact

This is a capability-isolation failure, not a claim of code execution on the ADK host itself.

The issue is that a request/session configured without the CFC / built-in code-execution capability can receive that capability because a previous invocation using the same shared Agent enabled it.

This matters for long-lived shared Runner/Agent instances, especially where different sessions, users, or policy contexts use different per-invocation capabilities.

Fixed behavior

Commit f8282dafd3bc63476b76af31d1df3abdad6370fa removes the in-place mutation of Runner.agent and resolves BuiltInCodeExecutor dynamically per invocation in _code_execution.py.

Opening this issue for public tracking/documentation of the affected released behavior and the fix.