removeUserPrefix still lowercases peer ID, breaking parity with claude-honcho

[idrinkritalin]

Summary

removeUserPrefix: true is documented/intended to make the user peer ID match the sibling claude-honcho plugin's peer ID (per the comment in src/index.ts right above deriveUserPeerId), but it doesn't actually achieve parity, because normalizeId unconditionally lowercases the value:

const normalizeId = (value: string) =>
  trimHyphenEdges(value.toLowerCase().replace(/[^a-z0-9_-]+/g, "-")) || "default"

const deriveUserPeerId = (settings: Pick<HonchoSettings, "peerName" | "removeUserPrefix">) => {
  const name = settings.peerName || currentUserName()
  // removeUserPrefix=true drops the `user-` prefix to match the sibling
  // claude-honcho / hermes-honcho plugins; false (the legacy-safe default)
  // keeps the historical `user-<name>` peer and its accumulated memory.
  return settings.removeUserPrefix ? normalizeId(name) : normalizeId(`user:${name}`)
}

claude-honcho preserves the exact case of peerName as the peer ID (e.g. "Stefano"). Since Honcho peer IDs are case-sensitive, opencode-honcho with removeUserPrefix: true and peerName: "Stefano" still produces "stefano" ,a brand new, empty peer, disjoint from the one claude-honcho has been writing to.

Repro

1. Use claude-honcho with peerName: "Stefano" for a while, it creates/writes to Honcho peer "Stefano" in some workspace.
2. Install opencode-honcho, set the same peerName: "Stefano", same workspace, and hosts.opencode.removeUserPrefix: true.
3. Query Honcho (GET /v3/workspaces/{workspace}/peers/list) , instead of one shared peer "Stefano", there are two: "Stefano" (from claude-honcho) and "stefano" (from opencode-honcho, all lowercase).
4. Any honcho_chat/dialectic query in OpenCode comes back with "no memory yet" even though the Claude Code peer has substantial history, because it's reading a different peer.

Expected

With removeUserPrefix: true, the resulting peer ID should exactly match what claude-honcho would produce for the same peerName, so the two hosts genuinely share state as the shared ~/.honcho/config.json file (and the docs) imply. Given claude-honcho doesn't lowercase, deriveUserPeerId shouldn't run peerName through normalizeId's .toLowerCase() when removeUserPrefix is true (or at minimum, this case-folding behavior should be documented, since it silently breaks the "shared config across hosts" promise).

Suggested fix

Something like:

const deriveUserPeerId = (settings: Pick<HonchoSettings, "peerName" | "removeUserPrefix">) => {
  const name = settings.peerName || currentUserName()
  if (settings.removeUserPrefix) {
    // Preserve exact casing to match claude-honcho's peer id derivation.
    return trimHyphenEdges(name.replace(/[^a-zA-Z0-9_-]+/g, "-")) || "default"
  }
  return normalizeId(`user:${name}`)
}

(or expose an explicit preserveCase / raw peerId override in hosts.opencode config as an escape hatch.)

Environment

• @honcho-ai/opencode-honcho: latest (resolved 0.1.3 at time of filing)
• opencode: 1.18.9

[idrinkritalin]

For context on how removeUserPrefix came about, in case it helps prioritize: this traces back to #22 → #23 → #24.

• User peer naming is inconsistent with the other Honcho plugins #22 reported the prefix mismatch (user-<peerName> vs. sibling plugins' bare <peerName>).
• fix: use bare peerName for the user peer to match sibling plugins #23 (@rrei) fixed it by dropping the prefix unconditionally, but that would've silently re-pointed existing users at a brand-new empty peer.
• fix: gate user-peer prefix on hosts.opencode.removeUserPrefix #24 (merged) is the version that shipped: it gated the prefix-drop behind hosts.opencode.removeUserPrefix so fresh installs get the bare name and upgrades keep the legacy prefixed peer, avoiding orphaned memory.

Both #23 and #24 frame the fix as "match sibling plugins," and both are correct about the user: prefix specifically. Neither touches normalizeId's .toLowerCase(), though, which predates both PRs and is the other half of the parity gap described above. So removeUserPrefix: true fixes the prefix but not the casing, for any peerName with uppercase characters, it's still a different peer than what claude-honcho writes to, just for a different reason than #22 described.