Commit 5e1197a4 swapped the inline `os.path.exists('/.dockerenv')` check in
`detect_audio_environment()` for the more thorough `is_container()` helper
in `hermes_constants` (also matches /run/.containerenv and /proc/1/cgroup
markers, with module-level caching). That helper correctly returns True on
CI runners that themselves run inside Docker, which silently appended a
"Running inside Docker container" warning to every detection scenario and
broke four tests whose contract is "should be available":
- test_clean_environment_is_available
- test_wsl_with_pulse_allows_voice
- test_wsl_device_query_fails_with_pulse_continues
- test_termux_api_microphone_allows_voice_without_sounddevice
The five "should be blocked" sibling tests passed only by coincidence —
the extra container warning still left `available=False`.
Fix:
- Hoist `is_container` to a module-level import in tools/voice_mode.py
so it's reachable as `tools.voice_mode.is_container` (matches the
monkeypatch convention used elsewhere in the test file for `shutil`,
`_import_audio`, `_termux_api_app_installed`, etc).
- Add an autouse fixture in `TestDetectAudioEnvironment` defaulting
`is_container` to False, so tests don't inherit the host runner's
container state. Per `feedback_no_such_thing_as_flakes`: the failures
were a real environmental coupling bug, not a flake.
- Add `test_docker_container_blocks_voice` to preserve and pin the
container-blocks-voice intent that the original inline check encoded.
Partial close hermes-agent#9.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
