hermes - 💡(How to fix) Fix Config env expansion should accept shell-style $VAR placeholders [1 pull requests]

Summary

Hermes currently expands ${VAR} placeholders in config.yaml, but leaves shell-style $VAR placeholders untouched. In practice this can cause confusing auth/config failures when users naturally write $MODELSCOPE_API_KEY or similar values in auxiliary provider config.

Impact

This breaks otherwise-correct configurations because the unresolved literal string gets forwarded as the API key or config value. A concrete example is auxiliary provider setup, where $MODELSCOPE_API_KEY can survive expansion and lead to persistent 401/auth failures.

Reproduction

1. Put a shell-style env reference in ~/.hermes/config.yaml, e.g. api_key: $MODELSCOPE_API_KEY
2. Ensure the environment variable is actually present.
3. Load Hermes config through the normal config-loading path.
4. Observe that the value remains the literal string $MODELSCOPE_API_KEY instead of expanding.

Expected behavior

Either:

• Hermes should support both documented ${VAR} and common shell-style $VAR placeholders, or
• it should reject $VAR explicitly with a clear error.

Proposed fix

Teach _expand_env_vars() to expand both forms while preserving current ${VAR} behavior and keeping unresolved placeholders verbatim.

Notes

A fix has been implemented locally with regression tests covering:

• direct $VAR expansion
• unresolved $VAR passthrough
• mixed ${VAR} + $VAR
• load_config() and load_cli_config() paths