When sharedSessions is set in honcho.json, the plugin merges context from each listed Honcho session into the recall payload. Lets canonical / hydrated corpora populated by separate tooling be available to dialogue recall without changing per-thread session isolation.

Default: empty list (no behavior change).

• HonchoClientConfig: new shared_sessions field, parsed from sharedSessions
• HonchoMemoryManager: stores list, get_session_context merges shared session context as result[shared_context] = [{session_id, summary, recent_messages}, ...]
• honcho_context tool: renders shared_context under "Shared canonical context" section

What does this PR do?

Related Issue

Fixes #

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

How to Test

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:

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

For New Skills

• This skill is broadly useful to most users (if bundled) — see Contributing Guide
• SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
• No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools)
• I've tested the skill end-to-end: hermes --toolsets skills -q "Use the X skill to do Y"

Screenshots / Logs

Description

Problem

The Honcho plugin resolves a per-thread session ID for each chat (via sessionStrategy: per-directory or gateway_session_key for gateway platforms). Dialogue recall (get_session_context) reads from that session only. Canonical knowledge that lives in dedicated Honcho sessions populated by external tooling (hydration pipelines, governance corpora, knowledge bases ingested by separate processes) is invisible to Hermes during dialogue.

This is intentional behavior for chat isolation, but it blocks a real use case: operators who maintain canonical knowledge stores in Honcho want that content available to Hermes recall without breaking the per-thread isolation that protects user privacy across conversations.

Solution

Add an opt-in sharedSessions config field to the honcho plugin. When set, the plugin merges context from each listed session into the recall payload, in addition to the per-thread session that's resolved by the existing logic.

// honcho.json
{
  "workspace": "hermes",
  "peerName": "user",
  "aiPeer": "hermes",
  "sessionStrategy": "per-directory",
  // NEW: optional list of additional sessions whose context is merged into recall
  "sharedSessions": ["governance-canonical", "knowledge-base-2026"]
}

Default: empty list. No behavior change for existing users.

Code structure

Three files modified, ~54 lines added:

1. plugins/memory/honcho/client.py — HonchoClientConfig gains a shared_sessions: list[str] field. Parsed from sharedSessions in the JSON config (with host_block fallback consistent with other fields).

2. plugins/memory/honcho/session.py — HonchoMemoryManager.__init__ stores self._shared_sessions. get_session_context calls self.honcho.session(sid).context(summary=True) for each shared session, extracts summary + recent messages, and appends to the result under a new shared_context key:

   result["shared_context"] = [
       {"session_id": "...", "summary": "...", "recent_messages": [...]},
       ...
   ]

3. plugins/memory/honcho/__init__.py — The honcho_context tool renders shared_context under a labelled ## Shared canonical context section so consumers can distinguish active-session content from shared content.

Failure modes

Each shared session fetch is wrapped in try/except. A failed lookup (session doesn't exist, network blip, permissions) logs at debug level and falls through. No exception propagates to break the dialogue. Per-shared-session failures are isolated; one bad ID doesn't kill the whole recall.

Backward compatibility

• New field defaults to [].
• No change to existing recall, session resolution, observation, or write paths.
• Existing tests should continue to pass without modification.

Use case (motivating the change)

The reporter maintains a self-hosted federated memory architecture where Cowork (Claude Desktop) writes session summaries to a canonical Honcho session via separate hydration tooling. With this change, the operator sets sharedSessions: ["hermes-canonical"] in honcho.json and Hermes-via-Discord can answer questions grounded in the Cowork-written corpus while still maintaining per-thread isolation for live chat conversations.

Verification

Locally verified end-to-end:

1. Branch checked out: feature/shared-sessions-recall, commit 42d2962d4.
2. Module imports clean: from plugins.memory.honcho.client import HonchoClientConfig shows the new field with default [].
3. Config parses: HonchoClientConfig.from_global_config() correctly loads sharedSessions: ["hermes"] into shared_sessions: ['hermes'].
4. Gateway restarted with patched plugin, clean startup, single process.
5. Discord retest: "What is MARKER_FEDARCH_REVIEW_LAVENDER?" — Hermes responds "The injected memory context confirms..." and surfaces the marker from the shared session content, confirming the merge path is functioning.

Optional follow-up

• Add a sharedSessionsMaxMessages int field if 5 recent messages per session isn't the right default for some operators.
• Consider plumbing the user's query through to get_session_context so each shared session can also do a semantic search instead of just returning the last N messages. Separate PR.
• Add tests under tests/honcho_plugin/ exercising the merge path with mock Honcho sessions.

Diff stat

 plugins/memory/honcho/__init__.py | 16 ++++++++++++++++
 plugins/memory/honcho/client.py   |  8 ++++++++
 plugins/memory/honcho/session.py  | 30 ++++++++++++++++++++++++++++++
 3 files changed, 54 insertions(+)

How to submit

From the dell WSL shell with the feature branch checked out:

cd ~/.hermes/hermes-agent
# Push the branch to your own fork (you'll need to fork on GitHub first)
git remote add fork https://github.com/<your-username>/hermes-agent.git
git push fork feature/shared-sessions-recall

# Open the PR via GitHub web UI:
#   https://github.com/<your-username>/hermes-agent/pull/new/feature/shared-sessions-recall
# Target: NousResearch/hermes-agent main branch
# Use the title + description above

Or use gh if installed:

gh pr create \
  --repo NousResearch/hermes-agent \
  --head <your-username>:feature/shared-sessions-recall \
  --title "Add sharedSessions config for cross-session recall in Honcho plugin" \
  --body-file /mnt/c/Users/GrahamNewlon/Documents/Claude/Projects/Hermes\ Agent/hermes-agent-PR-description.md