Skip to content

fix(execute_code): forward docker_env/forward_env/extra_args to spawned containers#30097

Open
elozadaf wants to merge 1 commit into
NousResearch:mainfrom
elozadaf:fix/execute-code-docker-config-parity
Open

fix(execute_code): forward docker_env/forward_env/extra_args to spawned containers#30097
elozadaf wants to merge 1 commit into
NousResearch:mainfrom
elozadaf:fix/execute-code-docker-config-parity

Conversation

@elozadaf

Copy link
Copy Markdown

What does this PR do?

_get_or_create_env() in code_execution_tool.py builds the container_config dict for the execute_code sandbox, but omitted three docker keys. terminal_tool.py already forwards all three when it builds its own container_config, so execute_code-spawned containers ran without host env vars, forwarded env, or extra docker flags — while terminal-spawned containers had them. The two tools spawn the same kind of container but were not at parity.

This adds the missing keys:

"docker_env": config.get("docker_env", {}),
"docker_forward_env": config.get("docker_forward_env", []),
"docker_extra_args": config.get("docker_extra_args", []),

Concrete symptom: a tool that depends on a host service from inside an execute_code container fails — e.g. a keyring-backed CLI can't reach the host secret service because the docker-default AppArmor profile blocks D-Bus, and the --security-opt apparmor=unconfined override (a docker_extra_args value) never reached the container. The same code under the terminal tool worked.

The keys default to {} / [] / [], so this is a no-op for any setup that doesn't configure them.

Related Issue

No tracking issue — found while debugging a host-service integration that worked under terminal but failed under execute_code.

Fixes #

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

  • tools/code_execution_tool.py_get_or_create_env() adds docker_env, docker_forward_env, docker_extra_args to container_config
  • tests/tools/test_code_execution_container_config.py — 6 tests (forwarding + defaults), mirroring the existing test_file_tools_container_config.py

How to Test

  1. Run pytest tests/tools/test_code_execution_container_config.py -q — 6 passed.
  2. Set docker_extra_args/docker_env/docker_forward_env in the env config; the container the execute_code tool spawns now receives them (previously only terminal-spawned containers did).

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix
  • I've run the affected test suite — tests/tools/test_code_execution_container_config.py: 6 passed
  • I've added tests for my changes (6 new tests)
  • I've tested on my platform: Ubuntu (Linux 6.8)

Documentation & Housekeeping

  • I've updated relevant documentation — N/A
  • I've updated cli-config.yaml.example if I added/changed config keys — N/A (keys already exist and are consumed by terminal_tool)
  • I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
  • I've considered cross-platform impact — N/A (Docker-only path, no platform-specific code)
  • I've updated tool descriptions/schemas if I changed tool behavior — N/A (no schema change)

…ed containers

_get_or_create_env() builds container_config for the execute_code sandbox but
omitted docker_env, docker_forward_env and docker_extra_args. terminal_tool
already forwards all three (terminal_tool.py container_config build), so
execute_code-spawned containers ran without host env vars, forwarded env, or
extra docker flags while terminal-spawned ones had them.

Concrete symptom: tools relying on a host service from inside an execute_code
container fail — e.g. a keyring-backed CLI cannot reach the host secret
service because the docker-default AppArmor profile blocks D-Bus, and the
--security-opt apparmor=unconfined override (a docker_extra_args value) never
reached the container.

Add the three keys to container_config, defaulting to {} / [] / [] so the
change is a no-op for setups that don't configure them. Brings execute_code
to parity with terminal_tool.

Adds tests/tools/test_code_execution_container_config.py (6 tests), mirroring
the existing test_file_tools_container_config.py.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists tool/code-exec execute_code sandbox tool/terminal Terminal execution and process management labels May 21, 2026

@mohamedorigami-jpg mohamedorigami-jpg left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a clean fix for a real bug. The terminal_tool already forwarded docker_env / docker_forward_env / docker_extra_args to spawned containers, but code_execution_tool's equivalent path was missing them. This meant execute_code containers ran without env vars or custom docker flags that the user had configured.

Code change: 3 lines in container_config dict, matching the same keys terminal_tool uses. The defaults ({} and []) match the upstream convention.

Tests: 6 test cases cover the happy path for each key plus the default-behavior path for each. The test structure mirrors the existing test_file_tools_container_config.py which is the right pattern to follow.

One minor thing: the comment block at lines 624-629 is detailed (date, symptom, root cause). That's helpful for future readers but it's more of a commit message than an inline comment. If the team prefers minimal inline comments, this could be trimmed to just # Forward docker_env/forward_env/extra_args so execute_code containers match terminal_tool behavior. Not a blocker -- the comment is accurate.`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

P2 Medium — degraded but workaround exists tool/code-exec execute_code sandbox tool/terminal Terminal execution and process management type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants