Bug Description

After the last update, when starting Hermes agent from the CLI it seems to be sanitizing the .env file, which splits GLM_API_KEY and GLM_BASE_URL into:

G
LM_API_KEY=
G
LM_BASE_URL=

It appears to be trying to validate LM studio first and breaking the GLM_* convention.

Steps to Reproduce

1. Add GLM_API_KEY= to .env file
2. Run hermes
3. At inference it will fail due to no API key for Z.AI GLM
4. Exit hermes agent and check .env - GLM_API_KEY= will be split into G\nLM_API_KEY

Expected Behavior

Hermes agent does not sanitize the GLM_API_KEY/GLM_BASE_URL vars and leaves them intact

Actual Behavior

Hermes sanitizes the GLM_API_KEY/GLM_BASE_URL vars into G\nLM_API_KEY and G\nLM_BASE_URL, rendering them invalid for LM Studio and breaking the ZAI/GLM connection

Affected Component

Configuration (config.yaml, .env, hermes setup)

Messaging Platform (if gateway-related)

No response

Debug Report

I'm not comfortable sharing these publicly since for some reason it's including very identifiable information for me and my system.

Operating System

PopOS 24.04 LTS

Python Version

3.11.14

Hermes Version

0.11.0 (2026.4.23)

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

suffix collision in _sanitize_env_lines's known-key splitter.

Mechanism:

• hermes_cli/config.py registers both LM_API_KEY (for an "LM" provider, auth.py:174) and GLM_API_KEY (zai provider, auth.py:205) — and similarly LM_BASE_URL vs GLM_BASE_URL — in its KNOWN_ENV_VARS table (config.py:1226 / :1242).
• _sanitize_env_lines (config.py:~3677) walks each .env line scanning for any known-key name as a substring of the line and inserts a newline before each match to "split concatenated KEY=VALUE pairs."
• LM_API_KEY is a substring of GLM_API_KEY=, so the splitter matches at offset 1, inserts \n before LM_API_KEY, and writes the file back as G\nLM_API_KEY=…. Same logic mangles GLM_BASE_URL → G\nLM_BASE_URL=….
• Loading python-dotenv then sees G= (empty) and LM_API_KEY=… as separate vars, so os.environ["GLM_API_KEY"] is unset and downstream zai auth falls back to whatever else is configured

Proposed Fix (optional)

require key matches at line start (or anchored after \n), not as raw substrings — e.g., split only when the position is 0 or the preceding char is a non-identifier char ([^A-Za-z0-9_]). Same class of bug applies to any future env var name that's a suffix of another registered name.

Are you willing to submit a PR for this?

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