Problem

_sanitize_env_lines() in hermes_cli/config.py uses str.find() to detect concatenated KEY=VALUE pairs on a single line. This substring search causes false positives when one known env var name is a substring of another:

• LM_API_KEY= matches at position 1 inside GLM_API_KEY=<value>, because find() does not require a word boundary.
• The sanitizer then splits the valid entry into a bare G line and an LM_API_KEY=... line, destroying the key.
• On the next gateway startup, sanitize_env_file() runs again and sees the two fragments as-is (neither is a valid known key), preserving the corruption permanently.

This is a general bug — any pair of known keys where one name contains another as a substring is affected (e.g., API_KEY= inside OPENAI_API_KEY=, ANTHROPIC_TOKEN= inside ANTHROPIC_API_KEY=, etc.). The practical impact is limited because most users do not encounter the initial corruption that triggers the cycle.

Trigger scenario (CJK input methods)

The bug becomes a persistent data-loss issue when combined with CJK input methods (fcitx5, ibus). These can occasionally insert a stray newline in the middle of a pasted env var name, producing:

G
LM_API_KEY=<actual_value>

Once this corruption exists:

1. The old sanitizer has no merge logic — it preserves both fragments as-is.
2. If the user manually fixes the split (e.g., via sed), the sanitizer re-splits it on the next startup due to the substring match described above.
3. This creates a repair loop that makes the .env file unfixable without patching the code.

Fix

Pass 0 (new): Detect and merge split key names. If a line contains only uppercase letters/underscores (no =) and the next non-empty line, when concatenated, forms a known env var name with =, merge them.

Pass 1 (improved): Replace str.find() (arbitrary substring search) with str.startswith() at position 0 + forward offset scanning. This ensures concatenated key detection only matches actual key names at line/segment boundaries, never as substrings inside other key names.

Testing

Verified with these scenarios:

• Split key merge: G + newline + LM_API_KEY=<value> → GLM_API_KEY=<value>
• Normal key preserved: GLM_API_KEY=abc → GLM_API_KEY=abc
• Concatenated keys still split: KEY1=val1KEY2=val2 → two lines
• Comments/blanks preserved
• No false merge on unrelated uppercase text