patchcord 0.6.44 → 0.6.45

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "patchcord",
   "description": "Cross-machine agent messaging. Messages from other agents land in the inbox and wake the agent to reply.",
-  "version": "0.6.44",
+  "version": "0.6.45",
   "author": {
     "name": "ppravdin"
   },

package/agent-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "patchcord",
-  "version": "0.6.44",
+  "version": "0.6.45",
   "description": "Cross-machine agent messaging for Claude Code and Codex",
   "author": {
     "name": "ppravdin",

package/harnesses.json

@@ -25,7 +25,9 @@
   "harnesses": [
     {
       "id": "claude_code",
-      "aliases": ["claude"],
+      "aliases": [
+        "claude"
+      ],
       "cli": "claude",
       "kind": "terminal",
       "installer_scope": "project",
@@ -75,7 +77,10 @@
     },
     {
       "id": "grok",
-      "aliases": ["grok_cli", "grok_build"],
+      "aliases": [
+        "grok_cli",
+        "grok_build"
+      ],
       "cli": "grok",
       "kind": "terminal",
       "installer_scope": "project",
@@ -130,9 +135,9 @@
       "cli": "hermes",
       "kind": "terminal",
       "installer_scope": "env-directed",
-      "installer_config": "$HERMES_HOME/config.yaml if set, else the output of `hermes config path` if the binary resolves, else ~/.hermes/config.yaml",
+      "installer_config": "$HERMES_HOME/config.yaml if set, else the output of `hermes config path` if the binary resolves (which reflects the ambient profile), else ~/.hermes/config.yaml",
       "harness_scope": "per-profile-or-per-home",
-      "installer_defect": "WAS: the path was hardcoded to ~/.hermes/config.yaml. The installer never called `hermes config path` and did not know profiles exist, so installing while a non-default profile was active wrote the DEFAULT profile's config — the wrong file, silently. FIXED (scripts/lib/hermes-home.mjs, resolveHermesHome/resolveHermesConfigPath/resolveHermesSkillsDest, all three deriving from the same resolved home): HERMES_HOME from the environment, else a shelled `hermes config path` (which itself honours HERMES_HOME — the child inherits the environment), else the unchanged ~/.hermes fallback. Applies to config.yaml AND to where Hermes skills install (~/.hermes/skills/integrations was hardcoded in three more places, unaware of HERMES_HOME — a seat isolated by home for identity but not for skills is not isolated: skills are a guard, not documentation). mux measured two independent isolation mechanisms this way — HERMES_HOME and -p/--profile, both real, both giving a separate mcp_servers AND a separate .env — which is why harness_scope reads per-profile-or-per-home rather than per-profile alone. installer_scope changed from 'global' to 'env-directed' for the same reason: our installer's write target is no longer a fixed machine-wide path, it is wherever HERMES_HOME points when mux sets it, falling back to global only when nothing directs it. PROFILE SUPPORT DELIBERATELY NOT BUILT: -p/--profile is a second, separate isolation axis this installer does not resolve, understand, or accept a flag for. Whether `hermes config path`'s output already reflects an ambient active profile (e.g. via an env var hermes itself reads) is unknown without reading Hermes's own source or an install to test against — neither available here. If a user runs Hermes under a non-default profile without ALSO setting HERMES_HOME to match, this installer's write may land in a config that profile-launched Hermes never reads — the same silent-wrong-file failure this whole fix exists to close, just on the axis we chose not to resolve. Not yet released or observed end to end; version not bumped.",
+      "installer_defect": "WAS: the path was hardcoded to ~/.hermes/config.yaml. The installer never called `hermes config path` and did not know profiles exist, so installing while a non-default profile was active wrote the DEFAULT profile's config — the wrong file, silently. FIXED (scripts/lib/hermes-home.mjs, resolveHermesHome/resolveHermesConfigPath/resolveHermesSkillsDest, all three deriving from the same resolved home): HERMES_HOME from the environment, else a shelled `hermes config path` (which itself honours HERMES_HOME — the child inherits the environment), else the unchanged ~/.hermes fallback. Applies to config.yaml AND to where Hermes skills install (~/.hermes/skills/integrations was hardcoded in three more places, unaware of HERMES_HOME — a seat isolated by home for identity but not for skills is not isolated: skills are a guard, not documentation). mux measured two independent isolation mechanisms this way — HERMES_HOME and -p/--profile, both real, both giving a separate mcp_servers AND a separate .env — which is why harness_scope reads per-profile-or-per-home rather than per-profile alone. installer_scope changed from 'global' to 'env-directed' for the same reason: our installer's write target is no longer a fixed machine-wide path, it is wherever HERMES_HOME points when mux sets it, falling back to global only when nothing directs it. PROFILE AXIS: COVERED, AND MEASURED RATHER THAN CLAIMED. This entry previously said profile support was deliberately not built, and that a user on a non-default -p/--profile without a matching HERMES_HOME would still get the silent-wrong-file failure. That was WRONG and lead@mux-v2 disproved it on a real Hermes install (boca, 2026-08-20): `hermes profile use sticky1` then `hermes config path` answers $HERMES_HOME/profiles/sticky1/config.yaml. The shelled resolver therefore honours the ambient profile by construction, because Hermes resolves it, not us. The same measurement confirmed the output is a FILE path, so dirname() in resolveHermesHome is correct. Resolution order in full: HERMES_HOME set (a mux seat) uses it directly and the profile is correctly ignored; HERMES_HOME unset with a profile active gets the profile's config; no hermes binary falls back to ~/.hermes, and a host with no hermes has no hermes seat. Under a sticky profile skills land at .../profiles/<name>/skills/integrations - profile-local skills beside profile-local config, which is the intent. Shipped in 0.6.44.",
       "listener": {
         "wake": "realtime",
         "mechanism": "webhook-bridge",
@@ -146,7 +151,9 @@
     },
     {
       "id": "antigravity",
-      "aliases": ["agy"],
+      "aliases": [
+        "agy"
+      ],
       "cli": "antigravity",
       "kind": "terminal",
       "installer_scope": "project",
@@ -186,7 +193,13 @@
       "installer_scope": "global",
       "installer_config": "~/.codeium/windsurf/mcp_config.json",
       "harness_scope": "unknown",
-      "listener": { "wake": "none", "mechanism": null, "self_arm": false, "survives_wake": null, "evidence": "declared" }
+      "listener": {
+        "wake": "none",
+        "mechanism": null,
+        "self_arm": false,
+        "survives_wake": null,
+        "evidence": "declared"
+      }
     },
     {
       "id": "vscode",
@@ -196,7 +209,13 @@
       "installer_scope": "project",
       "installer_config": ".vscode/mcp.json",
       "harness_scope": "unknown",
-      "listener": { "wake": "none", "mechanism": null, "self_arm": false, "survives_wake": null, "evidence": "declared" }
+      "listener": {
+        "wake": "none",
+        "mechanism": null,
+        "self_arm": false,
+        "survives_wake": null,
+        "evidence": "declared"
+      }
     },
     {
       "id": "zed",
@@ -206,7 +225,13 @@
       "installer_scope": "global",
       "installer_config": "~/.config/zed/settings.json",
       "harness_scope": "unknown",
-      "listener": { "wake": "none", "mechanism": null, "self_arm": false, "survives_wake": null, "evidence": "declared" }
+      "listener": {
+        "wake": "none",
+        "mechanism": null,
+        "self_arm": false,
+        "survives_wake": null,
+        "evidence": "declared"
+      }
     },
     {
       "id": "cline",
@@ -216,7 +241,13 @@
       "installer_scope": "global",
       "installer_config": "cline_mcp_settings.json (VS Code globalStorage)",
       "harness_scope": "unknown",
-      "listener": { "wake": "none", "mechanism": null, "self_arm": false, "survives_wake": null, "evidence": "declared" }
+      "listener": {
+        "wake": "none",
+        "mechanism": null,
+        "self_arm": false,
+        "survives_wake": null,
+        "evidence": "declared"
+      }
     },
     {
       "id": "jcode",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "patchcord",
-  "version": "0.6.44",
+  "version": "0.6.45",
   "description": "Cross-machine agent messaging for Claude Code and Codex",
   "scripts": {
     "version": "node scripts/sync-plugin-version.mjs && git add .claude-plugin/plugin.json agent-plugin/plugin.json"

package/scripts/lib/hermes-home.mjs

@@ -48,28 +48,36 @@
 // SAME resolved home (resolveHermesHome), never computed independently —
 // the two must never be able to disagree about which home they mean.
 //
-// NOT VERIFIED END TO END: no Hermes install on this machine to observe
-// `hermes config path`'s actual output shape. Assumed to print the config
-// FILE path directly (its name is "config path", not "profile path" or
-// "home"), so step 2 takes dirname() of it as the home rather than
-// assuming a directory was printed. If that assumption is wrong, the whole
-// chain (config.yaml AND skills) is wrong together under step 2 rather
-// than disagreeing with each other — a shared, nameable failure mode
-// instead of a silent split.
+// VERIFIED, ON A REAL INSTALL. lead@mux-v2 measured both open questions on
+// boca (hermes installed, 2026-08-20) and answered them:
 //
-// PROFILES (-p/--profile) ARE DELIBERATELY NOT SUPPORTED HERE. mux measured
-// that Hermes parses -p/--profile even though --help does not list it, and
-// that each profile gets its own config.yaml AND its own .env — a second,
-// separate isolation mechanism from HERMES_HOME. This module resolves
-// HERMES_HOME only. No --hermes-profile flag exists, and none is planned
-// without first reading Hermes's own source or testing against a real
-// install to learn whether `hermes config path`'s output already reflects
-// an ambient active profile — neither is available here, so the honest
-// choice was not to guess. CONSEQUENCE A USER MUST KNOW: running Hermes
-// under a non-default profile without ALSO setting HERMES_HOME to match
-// means this installer's write may land in a config that profile-launched
-// Hermes never reads — the exact silent-wrong-file failure the rest of this
-// module exists to close, just on the axis this module does not resolve.
+//   $ hermes config path
+//   /home/p/.hermes/config.yaml           <- a FILE path, so dirname() is right
+//
+//   $ hermes profile use sticky1          <- sets the ambient sticky profile
+//   $ hermes config path
+//   $HERMES_HOME/profiles/sticky1/config.yaml   <- the PROFILE is honoured
+//
+// PROFILES (-p/--profile) ARE COVERED, BY CONSTRUCTION RATHER THAN BY CODE.
+// This comment previously said the opposite: that profiles were a second
+// isolation axis this module does not resolve, and that a user on a
+// non-default profile without a matching HERMES_HOME would still get the
+// silent-wrong-file failure. That was wrong. Hermes resolves the ambient
+// profile itself, and step 2 shells Hermes, so the answer arrives already
+// correct. The decision NOT to model Hermes's resolution and to ask the
+// binary instead is what covers an axis nobody wrote code for.
+//
+// Resolution order, in full:
+//   HERMES_HOME set (a mux seat)   -> used directly; the profile is correctly
+//                                     ignored, because the seat's home wins
+//   HERMES_HOME unset, profile on  -> `hermes config path` answers with the
+//                                     profile's own config
+//   no hermes binary               -> ~/.hermes, and a host without hermes
+//                                     has no hermes seat to get wrong
+//
+// One consequence to keep rather than fix: under a sticky profile, dirname()
+// puts skills at .../profiles/<name>/skills/integrations. Profile-local
+// skills beside profile-local config is coherent, and it is what we want.
 
 import { execSync } from "node:child_process";
 import { join, dirname } from "node:path";