hermes - 💡(How to fix) Fix Honcho memory prefetch hang on fresh CLI subprocess in v0.15.0 (regression from #27190)

Summary

In v0.15.0 (release/v0.15.0-strip-gui, commit b9e8b331c), fresh hermes chat -q subprocesses hang indefinitely in _ensure_workspace() of the Honcho memory plugin when called from a cold-start process (e.g. cron jobs spawning new subprocesses, Paperclip-style ticket dispatchers using hermes chat -q ... as a CLI invocation).

The hang is reproducible on v0.15.0 and absent on 973f27e95 (the prior pin), which is the commit that landed fix(run_agent): isolate background review fork from external memory plugins (#27190). That commit's title and #27190's framing suggest v0.15.0 may have regressed the isolation it introduced.

Environment

• Hermes-agent: release/v0.15.0-strip-gui at b9e8b331c (released 2026-05-28)
• Python: 3.11.15 (cpython, uv-managed)
• OS: Linux (Hetzner CPX21 VPS, Ubuntu)
• Honcho plugin: enabled, cloud-hosted backend, workspace already created days prior
• Provider: OpenRouter (anthropic/claude-sonnet-4)
• Deployment shape: hermes-gateway systemd user service + hermes chat -q ... subprocess invocations from external dispatchers (Paperclip) and cron jobs

Repro

1. Pin Hermes at release/v0.15.0-strip-gui (b9e8b331c)
2. Run uv sync, restart hermes-gateway
3. Invoke a fresh CLI subprocess:

   timeout 30 hermes chat -q "respond with ok" -Q -m anthropic/claude-sonnet-4 --provider openrouter --yolo

Expected: "ok" returned within ~5 seconds.

Actual: Subprocess hangs in SSL.read until the timeout 30 kills it. Traceback at interrupt:

File ".../agent/conversation_loop.py", line 757, in run_conversation
  _ext_prefetch_cache = agent._memory_manager.prefetch_all(_query) or ""
File ".../agent/memory_manager.py", line 348, in prefetch_all
  result = provider.prefetch(query, session_id=session_id)
File ".../plugins/memory/honcho/__init__.py", line 582, in prefetch
  ctx = self._manager.get_prefetch_context(self._session_key)
File ".../plugins/memory/honcho/session.py", line 733, in get_prefetch_context
  user_ctx = self._fetch_peer_context(session.user_peer_id, ...)
File ".../plugins/memory/honcho/session.py", line 985, in _fetch_peer_context
  card = self._fetch_peer_card(peer_id, target=target)
File ".../plugins/memory/honcho/session.py", line 939, in _fetch_peer_card
  return self._normalize_card(getter(target=target) ...)
File ".../honcho/peer.py", line 468, in get_card
  self._honcho._ensure_workspace()
File ".../honcho/client.py", line 272, in _ensure_workspace
  self._http.post(routes.workspaces(), body={"id": self.workspace_id})
... → httpx → httpcore _receive_response_headers → SSL.read HANG

The hang is in the Honcho client's lazy workspace-ensure POST during the prefetch path's cold start, not in the LLM provider call.

Why the gateway-mediated path doesn't hang

Long-lived hermes-gateway runs (cron jobs that go through the gateway, Telegram conversations) work fine on v0.15.0. The hang is specific to fresh hermes chat -q subprocesses where the Honcho client has just been instantiated and _ensure_workspace() has never been called.

Hypothesis: gateway warms the Honcho connection pool on startup and reuses it; fresh subprocesses pay the cold-start _ensure_workspace POST and hang.

What works

• 973f27e95 (fix(run_agent): isolate background review fork from external memory plugins (#27190)): fresh subprocess returns "ok" cleanly within ~3 seconds with all the same env / Honcho config.

Asks

1. Confirmation of regression: is the isolation that #27190 introduced still intact in v0.15.0? If yes, what's the expected behavior for the fresh-subprocess Honcho prefetch path that hangs? If no, this is a regression to file under that commit's owners.
2. Workaround config flag (if regression isn't easy to revert): could we get a memory.prefetch.fresh_subprocess: false (or equivalent) config knob so deployments running CLI-dispatcher patterns can skip the prefetch in cold-start contexts without disabling Honcho memory globally?
3. Honcho client timeout: the hang is unbounded; consider adding a default timeout to the Honcho httpx client (e.g. 10s) so failures fail fast instead of hanging until upstream-imposed timeouts.

Related

• Original 2026-05-27 update attempt that surfaced this: hangs were observed but call site wasn't yet identified. Today's repro on v0.15.0 isolates the specific path.
• Codex TypeError fix (dc9d677d5) — the original reason for attempting the update; that fix is great and we want it. Just blocked from adopting by the Honcho prefetch hang.