It would not let me post this in the suggestions & ideas category so I guess it’s also an issue now due to the forum problem? Anyway:
Love that the R1 can drive Hermes now. One thing I’d love to see: the sessions picker on the R1 is always empty for Hermes.
Reason I’ve figured out: the connector launches a fresh hermes acp process for each session. ACP is scoped to sessions it creates itself, and per Hermes’ own docs, ACP can’t see ~/.hermes/state.db at all. So none of my existing Telegram or desktop app sessions show up, and I can’t resume them from the R1. The R1 gets a brand-new Hermes every time (it still knows me via memory, just no chat history).
The Hermes gateway is what actually owns all those sessions in one store. Hermes already has a relay/enroll mechanism for external connectors to feed into the gateway. If the R1 connector routed through the gateway instead of (or alongside) spawning hermes acp, the R1 could list and resume my existing Telegram/desktop sessions, and the picker would actually populate.
Not sure how much work that is on your side, but figured I’d raise it as a direction. Even just being able to resume the gateway’s sessions from the R1 would be a big step up from the current clean-slate-per-session model.
One more: the Claude Code integration currently spawns a fresh claude CLI session when the R1 targets it, which also starts clean each time. Claude Code has a remote-control mode (its --session-id / resume and the /resume and /projects remote session handling) that lets you reattach to an existing CLI session instead of starting new. If the R1 connector could connect to an already-running Claude Code session (or at least resume a previous one by session id) the same way, that’d match how I actually use Claude Code on the desktop — pick up where I left off rather than re-explain everything. Curious whether the connector could target a live Claude Code session over its control socket instead of shelling out a new claude each time.