Looks targeted at #463 — closes the small gap between WebUI /status and CLI status by surfacing the resolved Hermes home path.

Cross-checked the approach against the existing codebase:

• get_hermes_home_for_profile() is the right helper. It is already used in two other per-request paths (api/models.py line ~486 and api/streaming.py line ~1434) and its docstring explicitly calls out being "safe to call from per-request context … because it does not mutate process state." Using it in session_ops.py keeps /status consistent with how the rest of the WebUI resolves profile-scoped paths.

• No os.environ['HERMES_HOME'] = … mutation. The PR description specifically calls this out, and skimming the diff confirms it. Worth keeping vigilant about because mutating HERMES_HOME in a request handler would race with concurrent streams from other profiles — past bugs in this file have come from exactly that pattern.

A couple of things to keep an eye on in review:

1. Symlink and ~ expansion. If the resolved path contains a user's home dir or a symlink, the /status card will display whatever get_hermes_home_for_profile() returns. That's fine for parity with CLI, but worth confirming the displayed value is the same shape the CLI shows (e.g. both resolved or both un-resolved). If they differ, the /status card may look subtly different from hermes status in the terminal even though they refer to the same dir.

2. i18n string. static/i18n.js adds one new string for the home-path label — make sure the key gets translated for all six locales (en es de zh zh-Hant ru) eventually, even if it ships English-only first.

3. Default-profile vs named-profile coverage. The new tests in test_session_ops.py cover both, which is exactly the right pair of cases. Adding one assertion that the returned path is absolute (not relative) would harden against a future refactor of get_hermes_home_for_profile that accidentally returns a relative Path.

Small focused diff (3 prod lines + 14 test lines) refs an existing milestone-2 issue. Will defer merge to maintainer review.

Thanks for the quick i18n follow-up — the second commit (fix: add status home locale strings) addresses point 2 from my earlier review. Skimming the updated static/i18n.js, the status_hermes_home key is now present in the en, en-CA-style, es, de, zh-Hans, zh-Hant, pt, and ko blocks I checked, with reasonable native renderings (Hermes 主目錄, Hermes 홈, Diretório Hermes, etc.).

One small thing: I didn't spot a Russian (ru) and a Spanish-rest (es) match for the new key in the parts of the diff I saw — worth a quick grep -n status_hermes_home static/i18n.js | wc -l against your live locale count to confirm parity. If a locale is missing the key, the existing fallback chain in t() will paper over it (defaults to English), but it's nicer to ship complete coverage in one go.

Other than that, no change to the original review — small, focused, no HERMES_HOME env mutation, sensible test coverage. Will defer merge to maintainer review.

Released as part of v0.50.252 — thanks @NocGeek!

This PR was merged into the v0.50.252 release batch via #1387 alongside 5 other contributor fixes. The full CHANGELOG entry is at https://github.com/nesquena/hermes-webui/blob/master/CHANGELOG.md.

Pre-release verification: 3507 pytest tests pass, full QA harness pass (20 structural + 11 browser API + 23 Agent Browser CDP), Opus mentor APPROVED with two non-blocking follow-ups applied during the release batch (force=True on agent redactor, debug-log on profile fallback).

Closing this PR — the change is live on master.