Title: mnemon_recall crashes with NoneType.strip on Windows — stdout decoded as cp1252 instead of UTF-8
Summary
On Windows, mnemon_recall (and other CLI-backed calls) crash with:
Memory tool 'mnemon_recall' failed: 'NoneType' object has no attribute 'strip'
…whenever the recalled content contains non-cp1252 bytes (curly quotes ’, em-dashes —, etc. — very common in stored LLM output). It is not an input/argument problem; the query is a valid string.
Root cause
_run_mnemon invokes the mnemon CLI via subprocess.run(..., text=True) without specifying an encoding. On Windows, text=True decodes the child process's stdout using the locale default codec (cp1252), not UTF-8. mnemon emits UTF-8, so when the output contains a byte cp1252 can't map (e.g. 0x9d), the decode raises UnicodeDecodeError in the subprocess reader thread. As a result stdout comes back as None, and the downstream JSON parsing then calls .strip() on that None, producing the crash above.
This reproduces reliably under a cp1252 locale and never reproduces on Linux/macOS or in a UTF-8 shell — which is why it presents as Windows-only.
Impact
Any recall whose stored content includes typographic/Unicode characters (smart quotes, em-dashes, accented text) fails outright, so memory recall is effectively broken on default Windows setups once such content exists in the store.
Environment
OS: Windows 11, running via the Hermes desktop app (Python 3.11)
Plugin: hermes-plugin-mnemon 0.1.0, mnemon CLI 0.1.16
Trigger: recalled insights containing smart quotes / em-dashes
Title: mnemon_recall crashes with NoneType.strip on Windows — stdout decoded as cp1252 instead of UTF-8
Summary
On Windows, mnemon_recall (and other CLI-backed calls) crash with:
Memory tool 'mnemon_recall' failed: 'NoneType' object has no attribute 'strip'
…whenever the recalled content contains non-cp1252 bytes (curly quotes ’, em-dashes —, etc. — very common in stored LLM output). It is not an input/argument problem; the query is a valid string.
Root cause
_run_mnemon invokes the mnemon CLI via subprocess.run(..., text=True) without specifying an encoding. On Windows, text=True decodes the child process's stdout using the locale default codec (cp1252), not UTF-8. mnemon emits UTF-8, so when the output contains a byte cp1252 can't map (e.g. 0x9d), the decode raises UnicodeDecodeError in the subprocess reader thread. As a result stdout comes back as None, and the downstream JSON parsing then calls .strip() on that None, producing the crash above.
This reproduces reliably under a cp1252 locale and never reproduces on Linux/macOS or in a UTF-8 shell — which is why it presents as Windows-only.
Impact
Any recall whose stored content includes typographic/Unicode characters (smart quotes, em-dashes, accented text) fails outright, so memory recall is effectively broken on default Windows setups once such content exists in the store.
Environment
OS: Windows 11, running via the Hermes desktop app (Python 3.11)
Plugin: hermes-plugin-mnemon 0.1.0, mnemon CLI 0.1.16
Trigger: recalled insights containing smart quotes / em-dashes