patchcord 0.6.42 → 0.6.44

package/bin/patchcord.mjs

@@ -13,6 +13,7 @@ const __dirname = dirname(fileURLToPath(import.meta.url));
 const pluginRoot = join(__dirname, "..");
 import { resolveProjectBearer, harnessContext } from "../scripts/lib/resolve-project-bearer.mjs";
 import { detectClaudeLocalMcpOverride } from "../scripts/lib/claude-local-mcp.mjs";
+import { resolveHermesConfigPath, resolveHermesSkillsDest } from "../scripts/lib/hermes-home.mjs";
 const cmd = process.argv[2];
 
 /** Write a file then chmod 0600 (token-bearing configs must not be group/world readable). */
@@ -643,7 +644,7 @@ async function _resolveBearer(options = {}) {
     () => readJsonAt(join(HOME, ".gemini", "settings.json"), ["mcpServers", "patchcord"], "gemini"),
     () => readJsonAt(zedPath, ["context_servers", "patchcord"], "zed"),
     () => readJsonAt(join(HOME, ".openclaw", "openclaw.json"), ["mcp", "servers", "patchcord"], "openclaw"),
-    () => readHermesShape(join(HOME, ".hermes", "config.yaml")),
+    () => readHermesShape(resolveHermesConfigPath()),
     ...clinePaths.map((p) => () => readJsonAt(p, ["mcpServers", "patchcord"], "cline")),
   ];
   const globalCandidates = defaultGlobalCandidates;
@@ -683,6 +684,7 @@ if (cmd === "whoami") {
     codex: "codex", kimi: "kimi", "kimi-code": "kimi",
     opencode: "opencode", agy: "antigravity", antigravity: "antigravity",
     cursor: "cursor", grok: "grok", hermes: "hermes",
+    jcode: "jcode",
   };
   const resolveOpts = {};
   if (toolFlag) {
@@ -907,8 +909,28 @@ if (cmd === "upload") {
     console.error(`file is empty: ${filePath}`);
     process.exit(1);
   }
-  if (stats.size > 25 * 1024 * 1024) {
-    console.error(`file is ${(stats.size / 1024 / 1024).toFixed(1)}MB; max is 25MB for inline upload.`);
+  // THIS IS NOT THE UPLOAD LIMIT AND MUST NOT BE DESCRIBED AS ONE.
+  //
+  // It used to say "max is 25MB", which was wrong in both directions. The
+  // server's limit is PATCHCORD_ATTACHMENT_MAX_BYTES, 10 MiB by default and
+  // raisable on a self-hosted install. So this client refused files a
+  // configured server would have accepted, and accepted files every default
+  // server rejects: a 15 MB file passed here, got base64'd to 20 MB, was
+  // uploaded in full, and came back 413. A guard set above the real limit does
+  // not guard; it only pays the upload first.
+  //
+  // The client must not hold a copy of a number the server owns. What is left
+  // is a memory guard for THIS process: the file, its base64 (4/3 the size),
+  // and the JSON body are all resident at once. The real limit comes back from
+  // the server, in max_bytes, and is printed below.
+  const MEMORY_GUARD_BYTES = 256 * 1024 * 1024;
+  if (stats.size > MEMORY_GUARD_BYTES) {
+    console.error(
+      `file is ${(stats.size / 1024 / 1024).toFixed(1)}MB. This client buffers the ` +
+      `file and its base64 copy in memory and refuses above ` +
+      `${MEMORY_GUARD_BYTES / 1024 / 1024}MB. This is a client memory guard, not ` +
+      `the server's size limit — the server's limit is lower.`
+    );
     process.exit(1);
   }
 
@@ -923,7 +945,18 @@ if (cmd === "upload") {
     "POST", `${baseUrl}/api/agent/attachment/upload`, token, body
   );
   if (status !== "200") {
-    console.error(`✗ HTTP ${status}: ${(json && json.error) || respBody}`);
+    // Print max_bytes/allowed when the server sends them. Without this the user
+    // reads "attachment exceeds maximum size" and is not told the maximum, so
+    // their next move is to guess — or to ask an agent, which will guess.
+    let detail = "";
+    if (json && typeof json.max_bytes === "number") {
+      detail = ` (server limit ${(json.max_bytes / 1024 / 1024).toFixed(1)}MiB` +
+        (typeof json.actual_bytes === "number"
+          ? `, this file ${(json.actual_bytes / 1024 / 1024).toFixed(1)}MiB)` : ")");
+    } else if (json && Array.isArray(json.allowed)) {
+      detail = ` (allowed: ${json.allowed.join(", ")})`;
+    }
+    console.error(`✗ HTTP ${status}: ${(json && json.error) || respBody}${detail}`);
     process.exit(1);
   }
   console.log(json.path);
@@ -1500,15 +1533,95 @@ if (cmd === "login" || cmd === "orchestrator" || cmd === "teamlead" || cmd === "
       } catch {}
       return agWritten;
     }
+    if (tool === "jcode") {
+      // jcode is the ONLY harness here that gets a STDIO entry, and the reason
+      // is not preference: jcode has no HTTP transport. Its loader keeps an
+      // entry only when `is_stdio()` holds and drops the rest at load time --
+      // "MCP: Skipping non-stdio server '<name>' (http); HTTP/SSE transports
+      // are not yet supported" (crates/jcode-base/src/mcp/protocol.rs). So the
+      // `type: "http"` entry every other harness receives is READ, RECOGNISED
+      // AND DISCARDED by jcode, with a log line and no error. A bridge process
+      // is the only shape it can run today.
+      //
+      // NAMED patchcord-jcode, NOT patchcord, AND THAT IS LOAD-BEARING.
+      // jcode merges .jcode/mcp.json, then .mcp.json, then .claude/mcp.json,
+      // with later files overriding same-named servers. A guard currently saves
+      // us -- a non-stdio entry never displaces a working stdio one (their
+      // issue #653) -- but that guard holds only while jcode CANNOT run http.
+      // The day it gains that transport, a shared name means .mcp.json wins,
+      // and jcode silently starts authenticating as claude_code's agent: two
+      // harnesses, one credential, no error anywhere. A distinct name cannot
+      // collide in the first place. Codex already does this (patchcord-codex).
+      //
+      // The bridge command mirrors the OpenClaw fallback this file already
+      // prints. NOT VERIFIED END TO END from here: no jcode on this machine,
+      // and proving it needs a live token against the real endpoint.
+      const jdir = join(dir, ".jcode"); mkdirSync(jdir, { recursive: true });
+      const jcodeWritten = writeJson(join(jdir, "mcp.json"), (o) => {
+        o.mcpServers = o.mcpServers || {};
+        // No `type` key at all. jcode infers stdio from the presence of
+        // `command`, and writing "type": "stdio" is one more string to get
+        // wrong for a default that is already correct.
+        o.mcpServers["patchcord-jcode"] = {
+          command: "npx",
+          args: [
+            "mcp-remote",
+            `${baseUrl}/mcp`,
+            "--header",
+            `Authorization: Bearer ${token}`,
+            "--header",
+            `X-Patchcord-Machine: ${hostname}`,
+          ],
+        };
+      });
+      // THE SKILL IS A GUARD, NOT DOCUMENTATION, AND THIS IS THE HARNESS THAT
+      // PROVED WHY. jcode inherits Claude Code's plugin skills today, which
+      // say "spawn the listener under Monitor" — jcode has no Monitor, so
+      // that instruction produces a listener that connects, receives, and
+      // never wakes the agent. Observed in production: two messages sat
+      // unread behind a healthy-looking listener. Without jcode's own
+      // subscribe skill telling it to use `--stall-signal` + a bash
+      // background task instead, every jcode agent silently inherits the
+      // wrong instructions for its own harness.
+      //
+      // GLOBAL, NOT per-project (Pavel's ruling: "we dont need per project
+      // skills, only per project MCP settings needed") — mirrors the hermes
+      // branch above, not the antigravity one. `.jcode/mcp.json` stays
+      // per-project (every project = one namespace = one agent identity);
+      // skills are per machine, installed once, and MUST NOT contain
+      // anything project-specific as a result — no namespace, no agent name,
+      // no path baked in below.
+      //
+      // Destination is FLAT under ~/.jcode/skills/<name>/, not nested under
+      // an "integrations" folder like hermes — jcode's own loader
+      // (crates/jcode-app-core/src/tool/skill.rs) reads
+      // ~/.jcode/skills/<skill-name>/SKILL.md directly, verified from source,
+      // not the hermes shape.
+      try {
+        const jcodeSkillsSrc = join(pluginRoot, "per-project-skills", "jcode");
+        if (existsSync(jcodeSkillsSrc)) {
+          const jcodeSkillsDest = join(HOME, ".jcode", "skills");
+          for (const name of ["inbox", "subscribe", "wait"]) {
+            const from = join(jcodeSkillsSrc, name, "SKILL.md");
+            if (!existsSync(from)) continue;
+            const to = join(jcodeSkillsDest, name);
+            mkdirSync(to, { recursive: true });
+            cpSync(from, join(to, "SKILL.md"));
+          }
+        }
+      } catch {}
+      return jcodeWritten;
+    }
     if (tool === "hermes") {
-      // Hermes reads MCP servers ONLY from its GLOBAL ~/.hermes/config.yaml
-      // (mcp_servers key) — it ignores a project-local .mcp.json. So unlike the
-      // other tools we cannot write into `dir`; we upsert the global config,
-      // mirroring the `npx patchcord` installer's Hermes path. NOTE: global =
-      // one patchcord identity per machine, so provisioning a second hermes
-      // worker in another namespace overwrites the first's token. Single-hermes
-      // teams only until Hermes gains project-scoped MCP config.
-      const hermesPath = join(HOME, ".hermes", "config.yaml");
+      // Hermes reads MCP servers ONLY from its GLOBAL config.yaml (mcp_servers
+      // key) — it ignores a project-local .mcp.json. So unlike the other tools
+      // we cannot write into `dir`; we upsert the global config, mirroring the
+      // `npx patchcord` installer's Hermes path. NOTE: "global" here means one
+      // patchcord identity per Hermes HOME, so provisioning a second hermes
+      // worker under the SAME home overwrites the first's token. Isolated by
+      // HERMES_HOME (see resolveHermesConfigPath) or by -p profile — either
+      // gives a separate home, and therefore a separate identity.
+      const hermesPath = resolveHermesConfigPath();
       mkdirSync(dirname(hermesPath), { recursive: true });
       let existingYaml = "";
       try { existingYaml = existsSync(hermesPath) ? readFileSync(hermesPath, "utf-8") : ""; } catch {}
@@ -1518,7 +1631,7 @@ if (cmd === "login" || cmd === "orchestrator" || cmd === "teamlead" || cmd === "
       try {
         const hermesSkillsSrc = join(pluginRoot, "per-project-skills", "hermes");
         if (existsSync(hermesSkillsSrc)) {
-          const hermesSkillsDest = join(HOME, ".hermes", "skills", "integrations");
+          const hermesSkillsDest = resolveHermesSkillsDest();
           mkdirSync(hermesSkillsDest, { recursive: true });
           cpSync(hermesSkillsSrc, hermesSkillsDest, { recursive: true });
         }
@@ -1555,7 +1668,7 @@ if (cmd === "login" || cmd === "orchestrator" || cmd === "teamlead" || cmd === "
     console.error(`      .mcp.json         → claude_code`);
     console.error(`      .cursor/mcp.json  → cursor`);
     console.error(`  Defaulting would overwrite an agent you did not name, so there is no default.`);
-    console.error(`  One of: claude_code, codex, cursor, kimi, opencode, antigravity, grok, hermes`);
+    console.error(`  One of: claude_code, codex, cursor, kimi, opencode, antigravity, grok, hermes, jcode`);
     console.error(`  ${usage}`);
     process.exit(1);
   };
@@ -2915,11 +3028,14 @@ if (!cmd || cmd === "install" || cmd === "agent" || cmd?.startsWith("--")) {
 
   // Hermes — refresh patchcord skills to the current version on every run, so
   // skill fixes land via `patchcord update` (the interactive choice 13 only
-  // installs them once). ~/.hermes/skills is Hermes-only, so no leak risk; only
-  // refresh when the integrations dir already exists (Hermes was set up before).
+  // installs them once). Hermes's own skills dir is not shared with any
+  // other tool's config, so no leak risk; only refresh when the integrations
+  // dir already exists (Hermes was set up before) — resolved through the
+  // SAME home as config.yaml, so this refresh touches the seat's own skills
+  // under HERMES_HOME, not the operator's global ones.
   {
     const hermesSkillsSrc = join(pluginRoot, "per-project-skills", "hermes");
-    const hermesSkillsDest = join(HOME, ".hermes", "skills", "integrations");
+    const hermesSkillsDest = resolveHermesSkillsDest();
     if (existsSync(hermesSkillsDest) && existsSync(hermesSkillsSrc)) {
       let hermesChanged = false;
       for (const name of readdirSync(hermesSkillsSrc)) {
@@ -3194,7 +3310,7 @@ if (!cmd || cmd === "install" || cmd === "agent" || cmd?.startsWith("--")) {
     // falls through to no choice instead of silently configuring a DIFFERENT
     // harness and writing someone's token to the wrong file.
     "vscode": "6", "zed": "7", "opencode": "8", "openclaw": "9", "antigravity": "10",
-    "cline": "11", "kimi": "12", "hermes": "13",
+    "cline": "11", "kimi": "12", "hermes": "13", "jcode": "15",
   };
 
 
@@ -3583,6 +3699,7 @@ if (!cmd || cmd === "install" || cmd === "agent" || cmd?.startsWith("--")) {
   const isCline = choice === "11";
   const isKimi = choice === "12";
   const isHermes = choice === "13";
+  const isJcode = choice === "15";
 
   // MoonshotAI ships TWO CLIs that both use the `kimi` command:
   //   • kimi-cli (Python): supports `--mcp-config-file`, config in .kimi/mcp.json
@@ -3657,9 +3774,64 @@ if (!cmd || cmd === "install" || cmd === "agent" || cmd?.startsWith("--")) {
     } catch (e) {
       console.log(`\n  ${yellow}⚠ Failed to write ${grokPath}: ${e.message}${r}`);
     }
+  } else if (isJcode) {
+    // jcode: project-local .jcode/mcp.json, and a STDIO entry rather than the
+    // http one every other harness gets. jcode has no HTTP transport -- it
+    // recognises `type: "http"` and drops the server at load time with a log
+    // line. See the writeWorkerConfig branch above for why the entry is named
+    // `patchcord-jcode` and not `patchcord`; the short version is that jcode
+    // merges .jcode/mcp.json, .mcp.json and .claude/mcp.json by server NAME,
+    // so a shared name lets claude_code's credential silently become jcode's
+    // the day jcode gains http support.
+    const jcodePath = join(cwd, ".jcode", "mcp.json");
+    try {
+      mkdirSync(dirname(jcodePath), { recursive: true });
+      let jobj = {};
+      try { jobj = JSON.parse(readFileSync(jcodePath, "utf-8")); } catch {}
+      jobj.mcpServers = jobj.mcpServers || {};
+      jobj.mcpServers["patchcord-jcode"] = {
+        command: "npx",
+        args: [
+          "mcp-remote",
+          `${serverUrl}/mcp`,
+          "--header",
+          `Authorization: Bearer ${token}`,
+        ],
+      };
+      writeSecureFile(jcodePath, JSON.stringify(jobj, null, 2) + "\n");
+      console.log(`\n  ${green}✓${r} jcode configured: ${dim}${jcodePath}${r}`);
+      console.log(`  ${dim}Bridged over stdio — jcode does not speak HTTP MCP yet.${r}`);
+    } catch (e) {
+      console.log(`\n  ${yellow}⚠ Failed to write ${jcodePath}: ${e.message}${r}`);
+    }
+    // Install jcode skills to ~/.jcode/skills/<name>/ — GLOBAL, once per
+    // machine, not per project (Pavel's ruling: "we dont need per project
+    // skills, only per project MCP settings needed"). See the
+    // writeWorkerConfig branch above for the full guard-not-documentation
+    // reasoning and why the destination is flat, not nested under
+    // "integrations" the way hermes's is.
+    try {
+      const jcodeSkillsSrc = join(pluginRoot, "per-project-skills", "jcode");
+      if (existsSync(jcodeSkillsSrc)) {
+        const jcodeSkillsDest = join(HOME, ".jcode", "skills");
+        for (const name of ["inbox", "subscribe", "wait"]) {
+          const from = join(jcodeSkillsSrc, name, "SKILL.md");
+          if (!existsSync(from)) continue;
+          const to = join(jcodeSkillsDest, name);
+          mkdirSync(to, { recursive: true });
+          cpSync(from, join(to, "SKILL.md"));
+        }
+        console.log(`  ${green}✓${r} jcode skills installed: ${dim}${jcodeSkillsDest}${r}`);
+      }
+    } catch {}
   } else if (isHermes) {
-    // Hermes: global only (~/.hermes/config.yaml, YAML, mcp_servers key)
-    const hermesPath = join(HOME, ".hermes", "config.yaml");
+    // Hermes: global-per-home only (config.yaml, YAML, mcp_servers key). Same
+    // HERMES_HOME / `hermes config path` / ~/.hermes resolution as the
+    // writeWorkerConfig branch above — see resolveHermesConfigPath. Both
+    // write sites and the bearer-resolution read site must agree, or a seat
+    // provisioned here writes to one file while `patchcord whoami` verifies
+    // against another.
+    const hermesPath = resolveHermesConfigPath();
     mkdirSync(dirname(hermesPath), { recursive: true });
     let existingYaml = "";
     try { existingYaml = existsSync(hermesPath) ? readFileSync(hermesPath, "utf-8") : ""; } catch {}
@@ -3670,11 +3842,12 @@ if (!cmd || cmd === "install" || cmd === "agent" || cmd?.startsWith("--")) {
     } catch (e) {
       console.log(`\n  ${yellow}⚠ Failed to write ${hermesPath}: ${e.message}${r}`);
     }
-    // Install Hermes skills to ~/.hermes/skills/integrations/
+    // Install Hermes skills under the resolved home's skills/integrations/
+    // (same home as config.yaml — see resolveHermesSkillsDest).
     try {
       const hermesSkillsSrc = join(pluginRoot, "per-project-skills", "hermes");
       if (existsSync(hermesSkillsSrc)) {
-        const hermesSkillsDest = join(HOME, ".hermes", "skills", "integrations");
+        const hermesSkillsDest = resolveHermesSkillsDest();
         mkdirSync(hermesSkillsDest, { recursive: true });
         cpSync(hermesSkillsSrc, hermesSkillsDest, { recursive: true });
         console.log(`  ${green}✓${r} Hermes skills installed: ${dim}${hermesSkillsDest}${r}`);
@@ -4324,10 +4497,11 @@ if (!cmd || cmd === "install" || cmd === "agent" || cmd?.startsWith("--")) {
   // Hermes is global config (~/.hermes/config.yaml) — no per-project file to ignore.
   if (!isWindsurf && !isGemini && !isZed && !isOpenClaw && !isCline && !isHermes) {
     const gitignorePath = join(cwd, ".gitignore");
-    const configFile = isKimiCode ? ".kimi-code/mcp.json" : isKimi ? ".kimi/mcp.json" : isCodex ? ".codex/config.toml" : isCursor ? ".cursor/mcp.json" : isGrok ? ".grok/config.toml" : isVSCode ? ".vscode/mcp.json" : isOpenCode ? "opencode.json" : isAntigravity ? ".agents/mcp_config.json" : ".mcp.json";
+    const configFile = isJcode ? ".jcode/mcp.json" : isKimiCode ? ".kimi-code/mcp.json" : isKimi ? ".kimi/mcp.json" : isCodex ? ".codex/config.toml" : isCursor ? ".cursor/mcp.json" : isGrok ? ".grok/config.toml" : isVSCode ? ".vscode/mcp.json" : isOpenCode ? "opencode.json" : isAntigravity ? ".agents/mcp_config.json" : ".mcp.json";
     // Forms that already cover this config (its file or its dir)
     const patterns = [configFile];
-    if (isKimiCode) patterns.push(".kimi-code/");
+    if (isJcode) patterns.push(".jcode/");
+    else if (isKimiCode) patterns.push(".kimi-code/");
     else if (isKimi) patterns.push(".kimi/");
     else if (isCodex) patterns.push(".codex/");
     else if (isCursor) patterns.push(".cursor/");
@@ -4352,7 +4526,7 @@ if (!cmd || cmd === "install" || cmd === "agent" || cmd?.startsWith("--")) {
     }
   }
 
-  const toolName = isHermes ? "Hermes" : isKimiCode ? "Kimi Code" : isKimi ? "Kimi Code" : isAntigravity ? "Antigravity CLI" : isCline ? "Cline" : isOpenClaw ? "OpenClaw" : isOpenCode ? "OpenCode" : isZed ? "Zed" : isVSCode ? "VS Code" : isGemini ? "Gemini CLI" : isWindsurf ? "Windsurf" : isGrok ? "Grok CLI" : isCursor ? "Cursor" : isCodex ? "Codex" : "Claude Code";
+  const toolName = isJcode ? "jcode" : isHermes ? "Hermes" : isKimiCode ? "Kimi Code" : isKimi ? "Kimi Code" : isAntigravity ? "Antigravity CLI" : isCline ? "Cline" : isOpenClaw ? "OpenClaw" : isOpenCode ? "OpenCode" : isZed ? "Zed" : isVSCode ? "VS Code" : isGemini ? "Gemini CLI" : isWindsurf ? "Windsurf" : isGrok ? "Grok CLI" : isCursor ? "Cursor" : isCodex ? "Codex" : "Claude Code";
 
   if (!isWindsurf && !isGemini && !isZed && !isOpenClaw && !isCline && !isKimi && !isHermes) {
     console.log(`\n  ${dim}To connect a second agent:${r}`);

package/harnesses.json

@@ -129,10 +129,10 @@
       "aliases": [],
       "cli": "hermes",
       "kind": "terminal",
-      "installer_scope": "global",
-      "installer_config": "~/.hermes/config.yaml",
-      "harness_scope": "per-profile",
-      "installer_defect": "The path is hardcoded to ~/.hermes/config.yaml. The installer never calls `hermes config path` and does not know profiles exist, so installing while a non-default profile is active writes the DEFAULT profile's config — the wrong file, silently. Not fixed as of 0.6.41.",
+      "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",
+      "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.",
       "listener": {
         "wake": "realtime",
         "mechanism": "webhook-bridge",
@@ -217,6 +217,23 @@
       "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" }
+    },
+    {
+      "id": "jcode",
+      "aliases": [],
+      "cli": "jcode",
+      "kind": "terminal",
+      "installer_scope": "project",
+      "installer_config": ".jcode/mcp.json",
+      "harness_scope": "project",
+      "listener": {
+        "wake": "stall",
+        "mechanism": "subscribe-skill-stall-signal",
+        "self_arm": true,
+        "survives_wake": null,
+        "evidence": "declared",
+        "note": "STDIO ONLY FOR MCP; SKILLS ARE GLOBAL, NOT PROJECT. jcode reads .jcode/mcp.json, .mcp.json and .claude/mcp.json for MCP config (per-project, unchanged by this note), so it ALREADY finds the Claude Code entry we write - and drops it, because jcode supports stdio servers only and skips type http/sse at load time with a log line (crates/jcode-base/src/mcp/protocol.rs, retain on is_stdio). Server named patchcord-jcode, NOT patchcord, for the same reason codex uses patchcord-codex: a shared name would let a later file's entry silently override by NAME the day jcode gains http transport. jcode's own skills, separately, install ONCE GLOBALLY to ~/.jcode/skills/<name>/SKILL.md (verified from crates/jcode-app-core/src/tool/skill.rs's own loader paths) - not per project. WAKE IS \"stall\", NOT \"realtime\" OR \"none\": jcode has no Monitor, so a background task wakes it only when stdout goes quiet for stall_wake_seconds - and subscribe.mjs's only stdout writer is a real-message line, so by default the pipe is ALREADY silent while idle, making an unmodified stall wake fire on a timer regardless of whether anything arrived. `patchcord subscribe --stall-signal` (scripts/lib/stall-signal.mjs) inverts that for jcode specifically: writes a HEARTBEAT keepalive while idle so the pipe is never silently quiet by accident, and suppresses it on purpose after a real message so the stall condition elapses close to when the message actually arrived. This only works if stall_wake_seconds equals --stall-signal's own quiet window (15s by default) - a mismatch silently breaks the wake in one direction or the other, which is why the subscribe skill states the number explicitly rather than leaving it to be inferred. NOT VERIFIED END TO END: no jcode install on this machine to watch it actually fire."
+      }
     }
   ],
   "retired": [

package/package.json

@@ -1,9 +1,9 @@
 {
   "name": "patchcord",
-  "version": "0.6.42",
+  "version": "0.6.44",
   "description": "Cross-machine agent messaging for Claude Code and Codex",
   "scripts": {
-    "version": "node scripts/sync-plugin-version.mjs && git add .claude-plugin/plugin.json"
+    "version": "node scripts/sync-plugin-version.mjs && git add .claude-plugin/plugin.json agent-plugin/plugin.json"
   },
   "author": "ppravdin",
   "license": "MIT",
@@ -33,6 +33,7 @@
     "commands/",
     "README.md",
     "plugins/",
+    "agent-plugin/",
     "harnesses.json"
   ]
 }

package/per-project-skills/codex/SKILL.md

@@ -99,7 +99,7 @@ To message a user outside your namespace, use `@username` as the to_agent. Examp
 ```
 patchcord upload /path/to/report.md --mime text/markdown
 ```
-Prints the storage path. Pass it to `send_message`. No curl, no base64 in chat. 25MB cap.
+Prints the storage path. Pass it to `send_message`. No curl, no base64 in chat. The size limit belongs to the server: 10 MiB by default, raisable on a self-hosted server. Too large prints the server's own limit.
 
 **Public URLs → `attachment(relay=true, ...)`:**
 ```

package/per-project-skills/cursor/inbox/SKILL.md

@@ -105,7 +105,7 @@ To message a user outside your namespace, use `@username` as the to_agent. Examp
 ```
 patchcord upload /path/to/report.md --mime text/markdown
 ```
-Prints the storage path. Pass that path to `send_message`. No curl, no base64 in chat, no presigned URLs. 25MB cap.
+Prints the storage path. Pass that path to `send_message`. No curl, no base64 in chat, no presigned URLs. The size limit is the server's, not a number to remember: it is 10 MiB by default and a self-hosted server can raise it. If a file is too large the command prints the server's own limit.
 
 **Public URLs → `attachment(relay=true, ...)`:**
 ```

package/per-project-skills/jcode/inbox/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: patchcord-inbox
+description: Read Patchcord inbox and reply to messages
+---
+
+## Applies only when Patchcord MCP tools are loaded
+
+If the `inbox` MCP tool is not available in this session, this skill does not
+apply. Do nothing: do not run the Patchcord CLI, read a token from a config
+file, or call the HTTP API. A missing project MCP config is a normal state.
+
+Call the `inbox` MCP tool now. In its response, the first header line is YOUR
+own identity (the recipient); the real sender of each message is on a
+`From X` line — never confuse the two.
+
+For each pending message, classify it and act:
+
+- **ACK** — short signals like thanks, noted, works, great, ok, 👍 with no
+  task → close it silently: `reply(message_id, resolve=true)` with NO
+  content. Never send a text reply to an ack (it creates infinite ack
+  chains).
+- **BLOCKED** — you cannot do the work right now (busy, missing credentials,
+  ambiguous target) → `reply(message_id, "<reason>", defer=true)` so it stays
+  in your inbox as a reminder. Never silently skip a message.
+- **ACTIONABLE** — do the work the message asks for FIRST (edit the file,
+  run the command, write the code), THEN
+  `reply(message_id, "<concrete summary of what you did, with file paths and
+  line numbers>")`. Never reply "will do" / "understood" before doing the
+  work.
+
+If the patchcord-subscribe listener is already running in the background,
+you do not need to restart it after handling messages — unlike a
+poll-and-exit script, it keeps running across wakes. Only restart it if you
+have reason to believe it died (see the patchcord-subscribe skill).

package/per-project-skills/jcode/subscribe/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: patchcord-subscribe
+description: >
+  Start the Patchcord background listener so new messages wake this agent.
+  Run this when the user asks to start Patchcord push delivery.
+---
+
+jcode has no Monitor tool. A background task here wakes the agent on a
+STALL — no new output for N seconds — not per line the way Claude Code's
+Monitor does. Following Claude Code's own subscribe instructions verbatim on
+jcode produces a listener that connects, receives, and never wakes you: the
+pipe fills with messages you are never told about.
+
+This skill exists to run correctly on jcode specifically, using
+`patchcord subscribe --stall-signal`, a mode built for exactly this gap:
+while idle it writes a `HEARTBEAT:` line often enough that the pipe never
+looks silent, and on a real message it goes quiet on purpose for long enough
+that jcode's own stall detector fires. This is this repo's global skill
+directory (`~/.jcode/skills/`), shared by every jcode project on this
+machine — nothing below may name a specific namespace, agent, or project
+path.
+
+# Start
+
+1. **Drain the inbox first.** Call the Patchcord `inbox` MCP tool. Process
+   every pending message (see the patchcord-inbox skill) before starting the
+   listener — a backlog can accumulate while no listener was running, and
+   the listener does not replay what happened before it started.
+
+2. **Spawn the listener with bash, in the background, with a stall wake:**
+
+   ```
+   Bash(
+     command: "patchcord subscribe --stall-signal | grep --line-buffered '^PATCHCORD:'; exit ${PIPESTATUS[0]}",
+     run_in_background: true,
+     stall_wake_seconds: 15
+   )
+   ```
+
+   `stall_wake_seconds: 15` is not a placeholder — it MUST match
+   `--stall-signal`'s own default quiet window (15000ms). If you ever pass
+   `--stall-signal` a custom triple (`keepaliveMs:quietMs:stallMs`),
+   `stall_wake_seconds` must equal the `stallMs` you passed, or the two
+   numbers disagree and the wake either fires on nothing (too short) or
+   never fires on a real message (too long). Do not use 30 here — that
+   number predates `--stall-signal` and is shorter than nothing: it is
+   simply the wrong number for this mechanism, not a safer one.
+
+   The grep keeps only `PATCHCORD:` lines in the visible output; `HEARTBEAT:`
+   lines never match that pattern, so they never need special handling on
+   your end. `${PIPESTATUS[0]}` preserves subscribe's own exit code through
+   the pipe.
+
+3. **Tell the user one line:** "Patchcord listener active — I'll check
+   regularly for new messages." Do not say "as messages arrive" — the
+   mechanism approximates that, it does not guarantee it, and promising more
+   than jcode can deliver is worse than being accurate.
+
+# When the background task wakes you
+
+A wake means the pipe went quiet for `stall_wake_seconds` — with
+`--stall-signal` running, that quiet is now DESIGNED to correlate with a real
+message, but two other things also produce exactly the same silence, and you
+cannot tell which one happened from the wake alone:
+
+1. **Check the inbox every time.** Call the Patchcord `inbox` MCP tool. If it
+   has pending messages, handle them (see the patchcord-inbox skill). If it
+   is empty, say nothing to the user and do not report the wake as an event —
+   an empty check is not news.
+2. **If the inbox is empty, check whether the listener is still running**
+   before assuming this was a harmless false positive. A dead listener also
+   produces silence — that is a feature (it is how you notice), but only if
+   you actually look. If the background task has exited, restart it with the
+   command in Start, step 2.
+3. **Never read the last `PATCHCORD:` line in the task output as news.** It
+   is scrollback — output already displayed. It may be the same line you
+   already handled. The inbox call in step 1 is the source of truth; a
+   `PATCHCORD:` line without a corresponding inbox check is not confirmation
+   of anything.
+
+# Stopping
+
+Tell the user one of:
+
+- End this session.
+- Kill the listener: `kill $(cat /tmp/patchcord_subscribe_<namespace>_<agent>.pid)`
+  (the exact path is printed by `patchcord subscribe` on start; do not guess
+  the namespace/agent — this is a global skill and cannot know them).
+
+# If the background task ends on its own
+
+Read its output. Scan for one of:
+
+- `no patchcord config found` — not run from a project with `.jcode/mcp.json`
+  (or a parent project directory).
+- `ticket: token rejected (HTTP 401|403)` — the bearer token is invalid or
+  expired.
+- `already running (pid N)` (exit 2) — another listener is active for this
+  agent; report it, do not respawn.
+- `subscribe: fatal: ...` — report the fatal line verbatim.
+
+If none of those appear, it likely ended with the session or because its
+output consumer closed. Restart it only when the user asks to resume Patchcord
+push delivery.
+
+**Forbidden on failure:** no hand-rolled polling loop in place of this
+mechanism, no pidfile editing, no re-arm loop after every wake — the
+background task under `run_in_background` keeps running across wakes; you
+are only checking in, not restarting it, unless step 2 above found it dead.

package/per-project-skills/jcode/wait/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: patchcord-wait
+description: Wait for one incoming Patchcord message
+---
+
+## Applies only when Patchcord MCP tools are loaded
+
+If the `wait_for_message` MCP tool is not available in this session, this
+skill does not apply. Do nothing: do not run the Patchcord CLI, read a token
+from a config file, or call the HTTP API. A missing project MCP config is a
+normal state.
+
+Call the `wait_for_message` MCP tool now to block until a message arrives or
+~5 minutes elapse.
+
+When a message arrives, classify it and act:
+
+- **ACK** (thanks, noted, works, ok, 👍, no task) →
+  `reply(message_id, resolve=true)` with NO content. Never text-reply an ack.
+- **BLOCKED** (cannot do the work right now) →
+  `reply(message_id, "<reason>", defer=true)`.
+- **ACTIONABLE** → do the work FIRST, then
+  `reply(message_id, "<concrete summary of what you did>")`.
+
+Use this skill for a single blocking wait, not as a substitute for the
+persistent background listener — see the patchcord-subscribe skill for that.