patchcord 0.5.35 → 0.5.37

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "patchcord",
-  "version": "0.5.35",
+  "version": "0.5.37",
   "description": "Cross-machine agent messaging for Claude Code and Codex",
   "author": "ppravdin",
   "license": "MIT",

package/scripts/subscribe.mjs

@@ -383,9 +383,6 @@ function runOnce(ticket, baseUrl, token, refreshTicket) {
       if (rec.namespace_id && !allowedNs.has(rec.namespace_id)) return;
       // Only notify for messages addressed TO this agent — not our own outgoing replies.
       if (rec.to_agent && rec.to_agent !== ticket.agent_id) return;
-      // Skip resolved-ack messages (reply with resolve=true). These are terminal
-      // replies — waking the agent would restart the ack loop.
-      if (rec.thread_resolved_at) return;
       const from = rec.from_agent || "unknown";
       process.stdout.write(`PATCHCORD: 1 new from ${from}\n`);
     });

package/skills/inbox/SKILL.md

@@ -139,5 +139,6 @@ Named threads group related messages between a pair of agents. Use them for mult
 - **Do not reply to acks.** "ok", "noted", "seen", "thanks", "good progress", "keep running", thumbs up — anything that is clearly a conversation-ending signal. Just read them and move on. If you must close the thread, use `reply(id, resolve=true)` with NO content. Never send a text reply to an ack.
 - **resolve=true with ack-only content is an anti-pattern.** `reply(id, "Noted, thanks", resolve=true)` creates a new pending message the other side feels compelled to answer — producing ack chains. If you have nothing substantive to add, omit content entirely: `reply(id, resolve=true)`. Only include content with resolve when it carries new information the recipient needs.
 - **When you receive an ack**, close it silently: `reply(id, resolve=true)`. No content. This stops the chain.
+- **Messages with `thread_resolved_at` set are terminal.** The sender already closed the thread. Read the content, do not text-reply. If the message warrants acknowledgment, `reply(id, resolve=true)` with no content. Treating these as normal pending messages restarts the chain.
 - MCP tools are cached at session start. New tools deployed after your session began are invisible until you start a new session. If a tool you expect is missing, this is why.
 - Agent names change frequently. Do not memorize or hardcode them. Check inbox() for recent activity. When unsure which agent to message, ask the human.

package/skills/subscribe/SKILL.md

@@ -11,20 +11,22 @@ User invoked /patchcord:subscribe — do NOT substitute `wait_for_message()`. Sp
 
 # Start
 
-Spawn under Monitor (not Bash with run_in_background — Monitor turns each stdout line into a notification):
+1. **Drain the inbox first.** Call `mcp__patchcord__inbox`. If anything is pending, process it per the patchcord:inbox skill before continuing. Backlog can accumulate while no listener was up; subscribe must catch it.
 
-```
-Monitor(
-  description: "patchcord realtime listener",
-  persistent: true,
-  timeout_ms: 3600000,
-  command: "exec npx patchcord subscribe"
-)
-```
+2. **Spawn the listener under Monitor** (not Bash with run_in_background — Monitor turns each stdout line into a notification):
 
-`subscribe.mjs` handles its own pidfile guard — if another listener is already active for this agent it exits with code 2 and stderr `already running (pid N)`. Monitor catches the stream-end event; read the output file and report.
+   ```
+   Monitor(
+     description: "patchcord realtime listener",
+     persistent: true,
+     timeout_ms: 3600000,
+     command: "exec npx patchcord subscribe"
+   )
+   ```
 
-Then one line to the user: *"Patchcord listener active — I'll pick up new messages as they arrive."*
+   `subscribe.mjs` handles its own pidfile guard — if another listener is already active for this agent it exits with code 2 and stderr `already running (pid N)`. Monitor catches the stream-end event; read the output file and report.
+
+3. **Tell the user one line:** *"Patchcord listener active — I'll pick up new messages as they arrive."*
 
 # When a notification fires