Bug Description

When Hermes is configured with a custom OpenAI-compatible endpoint via OPENAI_BASE_URL + OPENAI_API_KEY in ~/.hermes/.env, commands run through the local terminal backend inherit those env vars unchanged. External CLIs like codex also honor OPENAI_BASE_URL, so they target the user's custom endpoint instead of OpenAI/Codex and fail unless the user manually unsets the variable first.

This is not just a shell/PATH workaround issue. Hermes currently reloads .env into the process and tools/environments/local.py passes the full os.environ to subprocesses. That makes the bug reproducible even when the parent shell initially started with OPENAI_BASE_URL unset.

Steps to Reproduce

1. Configure Hermes custom endpoint in ~/.hermes/.env:

OPENAI_BASE_URL=http://localhost:8000/v1
OPENAI_API_KEY=dummy

2. Use Hermes with the local terminal backend.
3. From Hermes, run an external CLI that also reads OpenAI env vars, e.g. codex exec "hello" (or any other OpenAI-compatible CLI that respects OPENAI_BASE_URL).
4. Observe that the external CLI inherits OPENAI_BASE_URL and tries to use the custom endpoint instead of its intended provider.
5. Manually unset OPENAI_BASE_URL for that command and it works.

Expected Behavior

Hermes should not leak provider env vars like OPENAI_BASE_URL / OPENAI_API_KEY into unrelated subprocesses by default. External CLIs should run with a safe baseline environment unless a command explicitly opts into those vars.

Actual Behavior

Hermes passes the full environment to subprocesses (tools/environments/local.py), so external CLIs inherit custom endpoint settings and can be silently misrouted or broken.

Affected Component

Terminal tool / local execution environment

Messaging Platform (if gateway-related)

Affects CLI and gateway-created terminal subprocesses because both load ~/.hermes/.env.

Operating System

macOS

Python Version

3.11

Hermes Version

Current upstream main as of 2026-03-12

Root Cause Analysis (optional)

The issue appears to come from the combination of:

• cli.py loading ~/.hermes/.env
• gateway/run.py loading and later reloading ~/.hermes/.env with override=True
• tools/environments/local.py building subprocess env from full os.environ
• external CLIs like codex honoring OPENAI_BASE_URL

This makes Hermes' custom endpoint setting leak across tool boundaries into external subprocesses.

Related Issues / PRs

• Related to Feature: Secure Secrets Management Tool — API Key Ingestion, Scoped Access, Redaction, and Skill Requirements #410 (terminal subprocess env leakage / env scoping)
• Related to fix: provider selection not persisting when switching via hermes model #881 and fix(setup): persist provider when switching model endpoints #951 (OPENAI_BASE_URL / provider persistence issues), but this bug is specifically about leaking Hermes provider env into external subprocesses

Proposed Fix (optional)

Use a safe env allowlist for terminal subprocesses by default, similar to the MCP tool, and add explicit opt-in env injection for commands/tools that truly need provider credentials. At minimum, OPENAI_BASE_URL and related provider vars should not be inherited by unrelated external CLIs by default.

Current Workaround

Prefix affected commands with:

env -u OPENAI_BASE_URL -u OPENAI_API_KEY codex ...

Are you willing to submit a PR for this?

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