fix(config): strip ASCII control characters from env values before writing to .env

[yubingz]

Fixes #40840

Problem

On Windows, pressing ESC or arrow keys during CLI prompts (hermes setup) inserts raw ANSI control characters (e.g. \x1b, \x1b[A) into input. These characters pass through prompt() → save_env_value() and get written to .env, silently corrupting configuration.

For example, a corrupted SEARXNG_URL like http://\x1blocalhost:8888 causes web_search to permanently fail with no clear error message — the user has no idea their config is broken.

Root Cause

1. Windows input() returns raw escape sequences on ESC/arrow key presses
2. prompt() only calls .strip() which does not filter control characters
3. save_env_value() strips non-ASCII but ESC (0x1b) is valid ASCII — it passes through
4. No URL prefix validation in _configure_provider() to catch malformed values

Fix: Three-Layer Defense

Layer 1 — Input Sanitization (config.py):

• Added _strip_control_chars(): strips C0 (0x00–0x1F except TAB 0x09) and C1 (0x80–0x9F) control characters
• TAB is preserved because some tools use it as a delimiter
• Called in save_env_value() before writing to .env — single point of defense for all env writes

Layer 2 — Business Validation (tools_config.py):

• Added http(s):// prefix validation in _configure_provider() for env vars ending in _URL, _HOST, or _ENDPOINT
• Catches malformed URLs that pass character sanitization but lack a valid scheme

Layer 3 — Regression Safety:

• 14 new tests in test_control_char_stripping.py covering ESC, arrow keys, mixed control chars, TAB preservation, etc.
• Updated comments in test_non_ascii_credential.py to clarify scope

Test Results

151 passed in 8.77s — 0 regressions

Files Changed

File	Change
hermes_cli/config.py	+78 lines: _strip_control_chars() + integration in save_env_value()
hermes_cli/tools_config.py	+18 lines: URL prefix validation in _configure_provider()
tests/hermes_cli/test_control_char_stripping.py	New file: 14 tests
tests/hermes_cli/test_non_ascii_credential.py	Updated test comments

[teknium1]

Thanks for addressing a real Windows configuration-corruption path. Current main still writes all ASCII controls other than LF/CR through save_env_value() (hermes_cli/config.py:7554-7618), while the shared non-secret prompt uses raw input() plus .strip() (hermes_cli/cli_output.py:63-65).

Problems

• tests/hermes_cli/test_control_char_stripping.py:125, :143, and :160 only inspect the result under if env_path.exists(). Those tests pass if the writer produces no .env file, so they do not prove the persistence behavior.
• The new URL-validation/retry branch in hermes_cli/tools_config.py:3084-3101 has no regression test. The current SearXNG plugin exposes SEARXNG_URL through this exact provider flow (plugins/web/searxng/provider.py:141-152).

Suggested changes

• Assert the file exists unconditionally, verify its saved value, and verify the process environment is sanitized too.
• Add a provider-flow test proving bare ESC is not saved and a valid http(s) retry is accepted.

Automated hermes-sweeper review.

[teknium1]

This conditional makes the integration test pass if save_env_value() returns without creating .env. Assert env_path.exists() unconditionally before reading it, then verify the persisted value (and ideally os.environ); the identical guards below should be changed too.