The `hermes:openExternal` route only accepted URL-parseable input, so every
bare local filesystem path a chat media link, a markdown href, or an
artifacts-panel value carried was a dead click: `new URL('C:\Users\x\a.md')`
parses a Windows drive letter as the bogus `c:` scheme (rejected by the web
allowlist as "Invalid external URL"), and POSIX `/...`, `~/...`, UNC and
relative paths make the parser throw into the same reject. Protocol-relative
`//cdn.example.com/img.png` URLs were also dead — the parser rejects them
without a base, and they are a URL, not a path.
- electron/local-filesystem-path.ts (new, from #84542): pure predicates —
`looksLikeLocalFilesystemPath` (POSIX, `~/`, drive, UNC; never `//host`)
and `absolutizeProtocolRelativeUrl` (`//host/...` opens as https).
- external-open.ts: a bare-path branch ahead of `new URL()` routes local
path shapes through a new `openLocalPath` dep; an unresolved path logs the
path and answers `invalid`, a thrown open reports through the existing
failure modal.
- main.ts: `openLocalFilesystemPath` resolves through the same audited
`resolveRequestedPathForIpc` as the `file:` route, runs the existing
missing-file pre-open stat guard, then `shell.openPath` with a
reveal-in-folder fallback — the reveal never re-opens, so archive artifacts
with no usable association can't loop (#53170). Open failures log the path
so "Failed to open path" is diagnosable.
Fixes https://github.com/NousResearch/hermes-agent/issues/80946
Co-authored-by: 686f6c61 <github@00b.tech>
Co-authored-by: Uttkarsh Tiwari <38376852+uttkarsh-26@users.noreply.github.com>
b5a5ef7c16