@paigy/mcp 0.40.39 → 0.40.41

package/README.md

@@ -109,26 +109,27 @@ Or add the entry to `~/.gemini/settings.json`:
 
 Then pair: `PAIGY_AGENT=gemini npx -p @paigy/mcp@latest paigy-mcp-onboard`.
 
-> `PAIGY_AGENT` names the agent AND keys its token slot (defaults to
-> `mcp-agent`). Each client reads only its own slot, so pair with the same
-> `PAIGY_AGENT` the client's config uses — and set it per client so you can
-> tell your connected agents apart.
+> `PAIGY_AGENT` names the agent AND keys its token slot. Without it, each session gets a private slot
+> (`session:<id>`); the shared `mcp-agent` default went on 2026-08-07. Each client reads only its own slot, so pair with the same
+> `PAIGY_AGENT` the client's config uses. A fixed `PAIGY_AGENT` makes every session of that client one agent: two running at once
+> collide, and the copy set aside is refused `holder_conflict` when it acts (#2933). `paigy-harness setup` wires clients without it,
+> so each session hatches its own identity.
 
 ## Tools
 
 One catalog, on every transport (2026-09-11): the agent tools are `AGENT_TOOLS` in
-`packages/schema/src/tools.ts` — contact, manage_goals, get_goals, search, check_activity,
-send_feedback — and both this server and the hosted MCP
+`packages/schema/src/tools.ts` (configure, contact, manage_goals, get_delivery, get_goals, search, check_activity,
+send_feedback), and both this server and the hosted MCP
 (`apps/api/src/mcp`) publish that list and dispatch it through the SDK's one `runTool`.
-This server adds only `configure`, the one identity tool, which pairs, reports who you are,
-renames and logs this agent out (`logOut: true`) over the token file this machine holds, and listen.
+This server extends `configure`, the one identity tool, which on the hosted MCP only reports who you are: here it also pairs,
+renames and logs this agent out (`logOut: true`) over the token file this machine holds. It adds `listen`.
 `onboard` is now `configure`; `pair` and `unpair` are folded into it (2026-10-07). See the [SDK contract](../../packages/sdk/README.md) for the
 contact shape. Sending returns immediately unless it asks to `wait`: `wait: true` holds one
 cancellable ~45-second window here for a response to what was sent (the hosted transport
 returns after one read), and `contact({})` holds one for anything addressed to you; after an
 `expired` window, wait again without sending again. Every Goal a contact names must already
 exist (create it with manage_goals); a question with `workItBlocks` asks for a call; a
-question, an update or an answer is at most 250 characters with its context in `units`; and
+question, an update or an answer is at most 80 characters with its context in `units`; and
 `withdrawQuestionIds` takes back a question of yours. `update_goal` is gone (2026-10-07): progress
 is a contact update (one the person does not need yet is kept as the Goal's progress), a review is
 acknowledged with `ackEventIds`, and a Goal is postponed with manage_goals `defer` (you are woken
@@ -145,9 +146,8 @@ time. Bookkeeping (`operationId`, the manage request id, the revision an edit wa
 minted here, never asked of the model. Retired
 reply-lease/ACK/work/callback tools and hidden notification aliases are rejected.
 
-The standalone listener below is still a **legacy host and target-release blocker**.
-Its old reply intake must migrate before enabling it against the target runtime; it is
-not a compatibility fallback for target MCP tools.
+Until 2026-09-13 the standalone listener below was a legacy host with its own reply intake. Since #1957 it reads
+the same `receive` as `contact({})`, as the next section says.
 
 ## Configuration
 
@@ -242,12 +242,12 @@ script and branch on `$PAIGY_EVENT` there:
 codex exec "Paigy goal $PAIGY_GOAL_ID. Read it with get_goals first. The user said: $PAIGY_TEXT. Reply with contact when done."
 ```
 
-## Stalled work (turn-end hook — Claude Code, Codex, Gemini CLI, Antigravity)
+## Stalled work (turn-end hook — Claude Code, Codex)
 
 An agent that goes quiet leaves its Goals behind. Three things hand it that work back, all
 reading one rule (no progress for 3 days, `COLD_AFTER_MS`): `contact({})` lists it under
 `stalled`, `paigy-listen` carries it in `PAIGY_WORK` (and launches for it on boot), and this
-hook holds a session's turn end once a day to list it. One program, four tools:
+hook holds a session's turn end once a day to list it. One program, two tools:
 
 **Claude Code** (`~/.claude/settings.json`) — installed by the paigy plugin:
 
@@ -267,19 +267,18 @@ command = "npx -y -p @paigy/mcp@latest paigy-stalled --agent codex"
 timeout = 60
 ```
 
-**Gemini CLI / Antigravity** (`~/.gemini/settings.json`, `~/.gemini/antigravity-cli/settings.json`)
-— the turn-end event there is `AfterAgent`, and the reminder also arrives as a `systemMessage`,
-which is the field that event promises will reach somebody:
-
-```json
-{ "hooks": { "AfterAgent": [{ "matcher": "*", "hooks": [{ "name": "paigy-stalled", "type": "command",
-  "command": "npx -y -p @paigy/mcp@latest paigy-stalled --agent antigravity", "timeout": 60000 }] }] } }
-```
+**Antigravity and Gemini CLI have no turn-end reminder (#3648).** Onboarding used to write one on
+`AfterAgent` into their `settings.json`; agy 1.4.1 reads hooks only from `hooks.json` and ends a turn
+on `Stop`, so it never fired, and in Gemini CLI's own file it named the wrong slot. `paigy-stalled`
+answers nothing on `AfterAgent` from this release on, so a copy goes quiet once its `npx` fetches
+it (the hook still starts `npx` each turn until removed), and onboarding (on every run) and
+`scripts/paigy-wipe.sh` take it out. A `Stop` hook in agy's `hooks.json` waits on a check of its
+payload on a real turn. The listener's wake and `contact({})`'s `stalled` still reach these agents.
 
 `--agent <slot>` is not optional outside Claude Code: a hook is not the MCP server, so it never
 inherits the `PAIGY_AGENT` that server was registered with, and without the flag it reads this
 session's own slot — a different identity, with no stalled work of its own. Pass the same value as
-the tool's MCP registration (`codex`, `antigravity`, or whatever you set `PAIGY_AGENT` to).
+the tool's MCP registration (`codex`, or whatever you set `PAIGY_AGENT` to).
 
 It is silent when nothing is stalled, when the stop is already being continued by a hook, and
 after it has reminded that session once today. Codex's older `notify` program is not a place for
@@ -306,12 +305,12 @@ machine is paired and this session's identity is minted by its first tool call;
 
 ## Publishing (maintainers)
 
-Tool input schemas are generated from zod in `src/schema.ts` as draft-2020-12 JSON
+Tool input schemas are generated from zod by `mcpInputSchema` (`packages/schema/src/mcp-schema.ts`) as draft-2020-12 JSON
 Schema, and `src/schema.test.ts` guards that every tool stays valid (strict clients
 like the Anthropic API reject anything else). **A schema fix only reaches agents once
 a new version is published to npm** — 0.8.0 once shipped *without* a committed fix and
-400'd strict clients for weeks. So after any change under `src/schema*` or the tool
-definitions: **bump the version and `pnpm publish`** (don't rely on the commit alone).
+400'd strict clients for weeks. So after any change to the tool schemas (`packages/schema`) or the tool
+definitions: **bump the version in `apps/mcp/package.json`**; publishing is `pnpm release` from the repo root, which the owner runs (`docs/infra/releasing.md`). Don't rely on the commit alone.
 Install recipes pin `@paigy/mcp@latest` so a fresh `npx` picks up the new version; if a
 stale one sticks, `rm -rf ~/.npm/_npx` and restart the client.
 

package/dist/{chunk-PMZBYLLJ.js → chunk-AX55W57P.js}

@@ -1,12 +1,13 @@
 import {
   NameTakenError,
+  ServerFault,
   isNetworkError,
   pollToken,
   requestCode,
   saveToken,
   setIdentity,
   sleep
-} from "./chunk-X4UIGUEX.js";
+} from "./chunk-CPDYOHSY.js";
 
 // src/identity.ts
 var CLIENT_LABELS = {
@@ -44,8 +45,9 @@ async function identify(who, ask) {
 }
 
 // src/pairing.ts
-async function resolvePairing(deviceCode, capMs, pollMs = 2e3) {
+async function resolvePairing(deviceCode, capMs, pollMs = 2e3, onFault) {
   const start = Date.now();
+  let fault;
   while (Date.now() - start < capMs) {
     try {
       const token = await pollToken(deviceCode);
@@ -53,8 +55,12 @@ async function resolvePairing(deviceCode, capMs, pollMs = 2e3) {
         saveToken(token);
         return { kind: "paired", token };
       }
+      fault = void 0;
+      onFault?.(fault);
     } catch (e) {
-      if (isNetworkError(e)) {
+      if (isNetworkError(e) || e instanceof ServerFault) {
+        fault = e.message;
+        onFault?.(fault);
         await sleep(pollMs);
         continue;
       }
@@ -62,12 +68,25 @@ async function resolvePairing(deviceCode, capMs, pollMs = 2e3) {
     }
     await sleep(pollMs);
   }
-  return { kind: "pending" };
+  return fault ? { kind: "pending", fault } : { kind: "pending" };
+}
+function pendingText(fault) {
+  if (fault) {
+    const said = /[.!?]$/.test(fault) ? fault : `${fault}.`;
+    return `Approval can't be checked right now: ${said} This is not the user being slow. Tell them once that Paigy is having trouble reaching its server, then call configure again with this device_code to keep trying; the code stays valid until it expires.`;
+  }
+  return "Still awaiting approval \u2014 the user hasn't entered the code yet. Call configure again with this device_code RIGHT NOW to keep waiting; each call returns after ~45s so it can't be killed by a host tool-call timeout. Nothing is lost between calls: the code stays valid and approval keeps being polled in the background, so a re-call returns the instant they approve.";
 }
 var bg = null;
 var started = null;
+var startedUntil = 0;
+function activePairing() {
+  if (started && Date.now() >= startedUntil) cancelBackgroundPair();
+  return started;
+}
 async function startPairing(agent) {
-  if (started) return started;
+  const live = activePairing();
+  if (live) return { ...live, expiresIn: Math.max(1, Math.round((startedUntil - Date.now()) / 1e3)) };
   const code = await requestCode(agent);
   started = {
     verificationUri: code.verification_uri_complete,
@@ -75,11 +94,14 @@ async function startPairing(agent) {
     deviceCode: code.device_code,
     expiresIn: code.expires_in
   };
+  startedUntil = Date.now() + code.expires_in * 1e3;
   startBackgroundPair(code.device_code, code.expires_in * 1e3);
   return started;
 }
 function startBackgroundPair(deviceCode, budgetMs) {
-  const promise = resolvePairing(deviceCode, budgetMs).catch((e) => ({ kind: "error", message: e.message })).then((o) => {
+  const promise = resolvePairing(deviceCode, budgetMs, void 0, (fault) => {
+    if (bg?.deviceCode === deviceCode) bg.fault = fault;
+  }).catch((e) => ({ kind: "error", message: e.message })).then((o) => {
     if (bg?.deviceCode === deviceCode) bg.settled = o;
     return o;
   });
@@ -106,7 +128,7 @@ async function joinBackgroundPair(deviceCode, capMs) {
     if (s.kind === "paired" || s.kind === "error") started = null;
     return s;
   }
-  return { kind: "pending" };
+  return bg?.fault ? { kind: "pending", fault: bg.fault } : { kind: "pending" };
 }
 function cancelBackgroundPair() {
   bg = null;
@@ -121,6 +143,7 @@ export {
   suggestedAgentName,
   identify,
   resolvePairing,
+  pendingText,
   startPairing,
   joinBackgroundPair,
   clearPairing