hermes - ✅(Solved) Fix [Bug]: execute_code silently returns tool_calls_made: 0 on Docker backend — HERMES_RPC_DIR not set in docker run [1 pull requests]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Additional Logs / Traceback (optional)

Root Cause

Root Cause Analysis (optional)

Fix Action

Fix / Workaround

Workaround: terminal.backend: local works correctly. Calling write_file as a top-level tool (not inside execute_code) also works — it's specifically the hermes_tools RPC bridge from inside execute_code that fails.

PR fix notes

PR #13342: fix(docker): pass RPC dir through exec env

Description (problem / solution / changelog)

Fixes #13142.

Root cause: execute_code set HERMES_RPC_DIR only through the remote shell prefix. On Docker, the file-based hermes_tools RPC bridge also needs the RPC directory in the container execution environment; without it, tool calls from inside execute_code could silently resolve to the wrong default and report tool_calls_made: 0.

Fix summary:

  • Thread optional per-call extra_env through the execution environment interface.
  • Pass HERMES_RPC_DIR as extra_env when running the remote execute_code script, while keeping the existing shell prefix for compatibility.
  • Apply extra_env to Docker via docker exec -e KEY=value and to the local backend via the subprocess environment.
  • Update other environment backends to accept the optional argument without changing their existing shell-prefix behavior.
  • Add regressions proving execute_code passes the RPC dir through extra_env and Docker turns it into docker exec -e HERMES_RPC_DIR=....

Tests:

  • uv run --frozen --python 3.11 --extra dev pytest -o addopts= tests/tools/test_code_execution.py tests/tools/test_docker_environment.py -q -> 83 passed, 1 warning
  • git diff --check -- tools/code_execution_tool.py tools/environments/base.py tools/environments/docker.py tools/environments/local.py tools/environments/ssh.py tools/environments/modal.py tools/environments/daytona.py tools/environments/singularity.py tests/tools/test_code_execution.py tests/tools/test_docker_environment.py

Note:

  • The warning is the existing fake-Popen drain-thread warning in tests/tools/test_docker_environment.py; the targeted suite passed.

Changed files

  • tests/tools/test_code_execution.py (modified, +39/-3)
  • tests/tools/test_docker_environment.py (modified, +24/-0)
  • tools/code_execution_tool.py (modified, +4/-0)
  • tools/environments/base.py (modified, +11/-4)
  • tools/environments/daytona.py (modified, +2/-1)
  • tools/environments/docker.py (modified, +8/-3)
  • tools/environments/local.py (modified, +3/-2)
  • tools/environments/modal.py (modified, +2/-1)
  • tools/environments/singularity.py (modified, +2/-1)
  • tools/environments/ssh.py (modified, +2/-1)

Code Example

Report     https://paste.rs/TYMHN
  agent.log  https://paste.rs/MiglU

---

20:25:19 - tools.code_execution_tool - INFO - Creating new docker environment for execute_code task 20260420...
20:25:20 - tools.environments.docker - INFO - Started container hermes-9f2ff599 (b9ec72897fd6)
20:25:20 - tools.environments.base - INFO - Session snapshot created (session=721ff9e435b8, cwd=/root)
20:25:21 - tools.code_execution_tool - INFO - Executing code on docker backend (task 20260420)...
20:25:21 - run_agent - INFO - tool execute_code completed (2.05s, 83 chars)
20:25:21 - root - DEBUG - Tool result (83 chars): {"status": "success", "output": "", "tool_calls_made": 0, "duration_seconds": 1.23}
RAW_BUFFERClick to expand / collapse

Bug Description

Environment Hermes Agent v0.10.0 (2026.4.16) Project: /home/ubuntu/.hermes/hermes-agent Python: 3.11.14 OpenAI SDK: 2.32.0 Up to date

Workaround: terminal.backend: local works correctly. Calling write_file as a top-level tool (not inside execute_code) also works — it's specifically the hermes_tools RPC bridge from inside execute_code that fails.

Steps to Reproduce

hermes config set terminal.backend docker hermes Prompt: Create hello.txt with "Hello, world!" using execute_code, then verify with read_file.

Expected Behavior

execute_code calls write_file() via hermes_tools, file appears, read_file returns content.

Actual Behavior

Every execute_code call returns {"status": "success", "output": "", "tool_calls_made": 0, "duration_seconds": ~1.2}. No file is created. write_file / read_file calls made from inside execute_code are silently dropped. print() output from within execute_code is also lost.

Affected Component

Tools (terminal, file ops, web, code execution, etc.)

Messaging Platform (if gateway-related)

No response

Debug Report

Report     https://paste.rs/TYMHN
  agent.log  https://paste.rs/MiglU

Operating System

Linux 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Python Version

3.11

Hermes Version

0.10

Additional Logs / Traceback (optional)

20:25:19 - tools.code_execution_tool - INFO - Creating new docker environment for execute_code task 20260420...
20:25:20 - tools.environments.docker - INFO - Started container hermes-9f2ff599 (b9ec72897fd6)
20:25:20 - tools.environments.base - INFO - Session snapshot created (session=721ff9e435b8, cwd=/root)
20:25:21 - tools.code_execution_tool - INFO - Executing code on docker backend (task 20260420)...
20:25:21 - run_agent - INFO - tool execute_code completed (2.05s, 83 chars)
20:25:21 - root - DEBUG - Tool result (83 chars): {"status": "success", "output": "", "tool_calls_made": 0, "duration_seconds": 1.23}

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

Use local backend

Are you willing to submit a PR for this?

  • I'd like to fix this myself and submit a PR

extent analysis

TL;DR

The issue can be worked around by using the local backend instead of Docker for the terminal.

Guidance

  • Verify that the write_file function works correctly when called outside of execute_code to confirm the issue is specific to the hermes_tools RPC bridge.
  • Check the logs from the hermes_tools and execute_code components to see if there are any error messages or clues about why the file is not being created.
  • Test the execute_code function with a simple print statement to see if the output is being lost due to the same issue.
  • Consider using the local backend as a temporary workaround until the issue with the Docker backend is resolved.

Example

No code snippet is provided as the issue seems to be related to the configuration and interaction between components rather than a specific code error.

Notes

The issue seems to be specific to the interaction between hermes_tools and execute_code when using the Docker backend. The fact that the write_file function works correctly when called outside of execute_code and that the local backend works correctly suggests that the issue is related to the Docker backend or the hermes_tools RPC bridge.

Recommendation

Apply workaround: Use the local backend for the terminal until the issue with the Docker backend is resolved, as it has been confirmed to work correctly.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix [Bug]: execute_code silently returns tool_calls_made: 0 on Docker backend — HERMES_RPC_DIR not set in docker run [1 pull requests]