fix(config): ignore corrupt install method stamp

[smwbev]

What does this PR do?

Makes install-method detection tolerant of a corrupt ~/.hermes/.install_method stamp file.

detect_install_method() already treats a missing/unreadable stamp as non-fatal and falls back to managed/container/git/pip detection. However, the stamp read only caught OSError; a malformed UTF-8 stamp raised UnicodeDecodeError, which could make hermes update --check or update-related recommendation paths crash before reaching the normal fallback logic.

This keeps the stamp as a best-effort hint: if it cannot be decoded, Hermes ignores it and continues with the existing detection order.

Related Issue

Related / prior art:

• Related: [Bug]: hermes update can crash with UnicodeDecodeError on config migration prompt in interactive TTY #12881 and fix(update): handle UnicodeDecodeError in post-update config migration prompt #12886 cover a similar UnicodeDecodeError symptom in the post-update interactive config-migration prompt (input()), but this PR fixes a separate path in detect_install_method().
• Related: feat(config): add install-method stamping + Docker detection #27843 introduced install-method stamping and the .install_method read path that this PR hardens.

No dedicated issue exists for a corrupt .install_method stamp.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• hermes_cli/config.py
  • Catch UnicodeDecodeError alongside OSError when reading ~/.hermes/.install_method.
  • Preserve the existing fallback behavior: managed install marker/env, container detection, git checkout, then pip fallback.
• tests/hermes_cli/test_pip_install_detection.py
  • Add a regression test where .install_method contains invalid UTF-8 (b"\xd0") and detection falls back to the project .git marker instead of crashing.

How to Test

1. Focused regression/unit tests:

   python -m pytest tests/hermes_cli/test_pip_install_detection.py tests/hermes_cli/test_cmd_update.py tests/hermes_cli/test_managed_installs.py -q -o 'addopts='

   Result:

   34 passed in 30.29s
   

2. Manual reproduction of the corrupt-stamp case:

   TMP=$(mktemp -d /tmp/hermes-pr-repro.XXXXXX)
   printf '\320' > "$TMP/.install_method"
   printf '_config_version: 24\nmodel:\n  provider: openrouter\n  default: test\n' > "$TMP/config.yaml"
   touch "$TMP/.env"
   HERMES_HOME="$TMP" hermes update --check

   Result after this change:

   → Fetching from upstream...
   → Fetching from origin...
   ✓ Already up to date.
   

3. Static checks:

   python3 -m py_compile hermes_cli/config.py tests/hermes_cli/test_pip_install_detection.py

4. Independent pre-commit review:

   • No security scan hits in added lines.
   • Reviewer verdict: passed; no security concerns or logic errors.

5. Full-suite check attempted:

   python -m pytest tests/ -q

   Local result: the run did not reach a passing state. GitHub CI currently reports failures in unrelated Kanban/Windows-guard tests that are outside this PR's diff (tests/tools/test_kanban_tools.py::test_worker_complete_rejects_stale_run_id and tests/tools/test_windows_native_support.py::TestKanbanWaitpidWindowsGuard::test_source_gates_waitpid_loop). I also reproduced those two failures on origin/main at 2d5dcfabc, where this PR's only changed files are not present.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Ubuntu 24.04 / Linux 6.17.9

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — N/A, no user-facing option or workflow change
• I've updated cli-config.yaml.example if I added/changed config keys — N/A, no config keys changed
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — this only broadens error handling around Path.read_text() and preserves existing fallback detection
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

Screenshots / Logs

Focused tests:

..................................                                       [100%]
34 passed in 30.29s

Manual corrupt-stamp smoke test:

exit=0
→ Fetching from upstream...
→ Fetching from origin...
✓ Already up to date.

[teknium1]

Thanks for the focused regression and best-effort fallback approach. The underlying defect still exists on current main.

Problems

• Current detect_install_method() has two UTF-8 stamp reads after 4440d77bf32d6267775be5eba2189e1ebde0b5b5: the code-scoped read at hermes_cli/config.py:433 and legacy home-scoped read at :445. Both catch only OSError (:436, :452). Applying the original one-site fix would leave the legacy compatibility path able to raise UnicodeDecodeError.
• The added test uses one tmp_path for both project_root and get_hermes_home, so it does not exercise the two current-main paths independently.

Suggested changes

• Apply the decode-error fallback to both stamp-read handlers.
• Add separate code/home directory regression cases for corrupt code-scoped and corrupt legacy home-scoped stamps, each asserting fallback to git detection.

Automated hermes-sweeper review.

[teknium1]

Current main has since split this into code-scoped and legacy home-scoped UTF-8 reads (hermes_cli/config.py:433 and :445, introduced by 4440d77bf). Salvage this same exception handling into both current handlers; otherwise a corrupt legacy home stamp still raises UnicodeDecodeError.

[GottZ]

This was generated by AI during triage.

Summary

Two PRs address this complex: merged #27843 introduced install-method stamping and the best-effort stamp read, while #33494 narrowly hardens that read against malformed UTF-8. The fix matches the reported failure mode, but its current diff covers only one of the two stamp-read paths now present on main.

Related pull requests

• #27843 [merged] related — (+74/-7) — merged foundation and relevant reference implementation: introduced .install_method stamping, precedence-based install-method detection, Docker handling, and the UTF-8 stamp read whose incomplete exception handling causes this defect.
• #33494 related — (+11/-1) — keep open and revise: correctly catches UnicodeDecodeError for one stamp read and adds a fallback regression test, but the contributor keep_open review identifies a second legacy home-scoped read on current main that remains crashable; the diff must cover both handlers and test code-scoped and home-scoped corrupt stamps independently.

Suggested consolidation

Merge #33494 after applying the decode-error fallback to both current-main stamp-read handlers and adding independent regression coverage for each path. #27843 is already merged and remains the relevant originating implementation, not a duplicate to close; there are no competing duplicate PRs in this complex.

Cross-PR triage: Reviewed 2 pull requests and 0 issues in this complex. Each diff was read against this issue; Assessment working set: 10 kB of PR diffs, 6 kB of issue/PR text, 2 kB of discussion (2 comments), 0 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.