Summary

On the docker terminal backend, environment variables listed in terminal.docker_forward_env (config.yaml) are never forwarded to the sandbox container. Agents running CLIs that depend on these vars (e.g. vercel, firebase, gh, etc.) fail with "no credentials" errors even though the vars are present in ~/.hermes/.env and correctly listed in the docker_forward_env whitelist.

Environment

• Hermes version: v0.10.0 (2026.4.16) — commit 3b69b2fd
• OS: Ubuntu 25.04 (x86_64)
• Backend: terminal.backend: docker, container_persistent: true
• Docker image: tested with both the default nikolaik/python-nodejs:python3.11-nodejs20 and a custom extension

Reproduction

1. ~/.hermes/.env contains:

   VERCEL_TOKEN=vcp_xxxxxxxxx
   VERCEL_ORG_ID=xxxxxxxx

2. ~/.hermes/config.yaml contains:

   terminal:
     backend: docker
     docker_forward_env:
       - VERCEL_TOKEN
       - VERCEL_ORG_ID
       - GITHUB_TOKEN
       # ...etc

3. Restart gateway (systemctl --user restart hermes-gateway.service).

4. Inside a Hermes session, run:

   echo "VT=${#VERCEL_TOKEN}"
   vercel whoami

Expected: VT=60, vercel whoami succeeds.

Actual: VT=0, vercel whoami fails with Error: No existing credentials found.

Root cause

In tools/terminal_tool.py, around line 1248, the container_config dict assembled for container backends (docker / singularity / modal / daytona) omits docker_forward_env and docker_env:

container_config = None
if env_type in ("docker", "singularity", "modal", "daytona"):
    container_config = {
        "container_cpu": config.get("container_cpu", 1),
        "container_memory": config.get("container_memory", 5120),
        "container_disk": config.get("container_disk", 51200),
        "container_persistent": config.get("container_persistent", True),
        "modal_mode": config.get("modal_mode", "auto"),
        "docker_volumes": config.get("docker_volumes", []),
        "docker_mount_cwd_to_workspace": config.get("docker_mount_cwd_to_workspace", False),
        # ❌ docker_forward_env and docker_env are MISSING here
    }

Then at line 707, build_environment reads cc.get("docker_forward_env", []) — which always returns [] because the key was never passed in — and instantiates DockerEnvironment(forward_env=[]).

As a result, _build_init_env_args() iterates over an empty forward_keys set and no -e KEY=VALUE flags are generated for the init_session docker exec, so the env snapshot captured by export -p never contains the user's whitelisted vars.

Confirmed via debug prints:

[HERMES-DEBUG] build_env: env_type=docker cc_keys=['container_cpu', 'container_disk', 'container_memory', 'container_persistent', 'docker_env', 'docker_forward_env', 'docker_mount_cwd_to_workspace', 'docker_volumes', 'modal_mode'] cc_fwd_len=0 TERMINAL_DOCKER_FORWARD_ENV=["GITHUB_TOKEN", ...]
[HERMES-DEBUG] _build_init_env_args: forward_keys_count=0 exec_env_count=0 os_environ_has_VERCEL_TOKEN=True

Note os.environ has the token (dotenv/bridge loaded it correctly), but forward_keys_count=0 because the list never made it into container_config.

Proposed fix

--- a/tools/terminal_tool.py
+++ b/tools/terminal_tool.py
@@ -1247,6 +1247,8 @@
                     container_config = {
                         "container_cpu": config.get("container_cpu", 1),
                         "container_memory": config.get("container_memory", 5120),
                         "container_disk": config.get("container_disk", 51200),
                         "container_persistent": config.get("container_persistent", True),
                         "modal_mode": config.get("modal_mode", "auto"),
                         "docker_volumes": config.get("docker_volumes", []),
                         "docker_mount_cwd_to_workspace": config.get("docker_mount_cwd_to_workspace", False),
+                        "docker_forward_env": config.get("docker_forward_env", []),
+                        "docker_env": config.get("docker_env", {}),
                     }

Tested locally — after applying this patch, the vars flow correctly from .env → os.environ → docker_forward_env list → -e flags at init_session → shell snapshot → agent commands.

Impact

This is silent: no warning, no error. Agents tasked with deployments, API calls or Git operations via CLI inside the sandbox appear to "not be authenticated" while the user believes the .env + docker_forward_env config is correct. Debugging requires reading sandbox source code.

Affected CLIs the community is likely to hit:

• vercel (token-based auth)
• firebase (GOOGLE_APPLICATION_CREDENTIALS)
• gh (GITHUB_TOKEN)
• Cloud SDKs relying on env-based auth (AWS, Supabase, Cloudflare, etc.)

Happy to open a PR with the 2-line fix + a regression test if useful.