Summary
_host_key() in plugins/memory/honcho/cli.py:238 returns f"{HOST}.{_profile_override}" when a profile override is set (e.g. hermes.fundraising for the fundraising profile). That dotted string can end up as the workspace_id sent to Honcho's API via the fallback in plugins/memory/honcho/client.py:373-378:
workspace = (
host_block.get("workspace")
or raw.get("workspace")
or resolved_host # ← falls back to _host_key() which has a dot
)
If a honcho.json host block doesn't have an explicit workspace field, the fallback returns the dot-form. Honcho's API rejects it with:
{'type': 'string_pattern_mismatch',
'loc': ['body', 'id'],
'msg': "String should match pattern '^[a-zA-Z0-9_-]+$'",
'input': 'hermes.fundraising'}
Why this surfaces
Running with --profile <name> produces logs like:
WARNING plugins.memory.honcho: Honcho init failed:
[{'type': 'string_pattern_mismatch',
'loc': ['body', 'id'],
'msg': "String should match pattern '^[a-zA-Z0-9_-]+$'",
'input': 'hermes.<profile_name>'}]
Once per minute. The Honcho memory plugin silently disables itself but the warning floods the journal.
Reproduce
- Configure Hermes with a non-default profile name, e.g.
myprofile.
- Initialize Honcho via the CLI (
hermes honcho setup), but DO NOT manually set the inner workspace field in the host block.
- Run with
--profile myprofile.
- Observe the warning in journal/logs.
Workaround (what we do)
Manually set honcho.json → hosts.<host_key>.workspace to an underscore-only string (e.g. hermes_myprofile). The explicit field wins over the fallback chain.
Proposed fix
One-line change in plugins/memory/honcho/cli.py:238:
- return f"{HOST}.{_profile_override}"
+ return f"{HOST}_{_profile_override}"
Plus a one-time migration helper for existing installs whose honcho.json outer keys are the dot-form: rename hosts."hermes.X" → hosts."hermes_X". The inner workspace field is already underscore-tolerant.
Impact
Cosmetic for users who set the explicit workspace field (no functional break). Real breakage for users relying on the fallback (their Honcho integration silently disabled).
Happy to send a PR with the rename + migration helper if you'd like — let me know.
Summary
_host_key()inplugins/memory/honcho/cli.py:238returnsf"{HOST}.{_profile_override}"when a profile override is set (e.g.hermes.fundraisingfor thefundraisingprofile). That dotted string can end up as theworkspace_idsent to Honcho's API via the fallback inplugins/memory/honcho/client.py:373-378:If a
honcho.jsonhost block doesn't have an explicitworkspacefield, the fallback returns the dot-form. Honcho's API rejects it with:Why this surfaces
Running with
--profile <name>produces logs like:Once per minute. The Honcho memory plugin silently disables itself but the warning floods the journal.
Reproduce
myprofile.hermes honcho setup), but DO NOT manually set the innerworkspacefield in the host block.--profile myprofile.Workaround (what we do)
Manually set
honcho.json→hosts.<host_key>.workspaceto an underscore-only string (e.g.hermes_myprofile). The explicit field wins over the fallback chain.Proposed fix
One-line change in
plugins/memory/honcho/cli.py:238:Plus a one-time migration helper for existing installs whose
honcho.jsonouter keys are the dot-form: renamehosts."hermes.X"→hosts."hermes_X". The innerworkspacefield is already underscore-tolerant.Impact
Cosmetic for users who set the explicit
workspacefield (no functional break). Real breakage for users relying on the fallback (their Honcho integration silently disabled).Happy to send a PR with the rename + migration helper if you'd like — let me know.