@paigy/mcp 0.40.23 → 0.40.25

package/README.md

@@ -117,7 +117,7 @@ Then pair: `PAIGY_AGENT=gemini npx -p @paigy/mcp@latest paigy-mcp-onboard`.
 ## Tools
 
 One catalog, on every transport (2026-09-11): the agent tools are `AGENT_TOOLS` in
-`packages/schema/src/tools.ts` — contact, check_replies, create_goal, claim_goal,
+`packages/schema/src/tools.ts` — who_is_working, contact, manage_goals, claim_goal,
 get_goal, update_goal — 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 onboard, pair and unpair, the tools that mint and delete the token
@@ -125,10 +125,12 @@ file this machine holds. See the [SDK contract](../../packages/sdk/README.md) fo
 single-Goal start shape. Notification returns immediately. Call holds one cancellable
 ~45-second window here (the hosted transport returns after one read); continue with
 contact({deliveryId}) without sending another ask. Durable Entries and accepted answers can
-repeat on reads; check_replies lists every open Delivery addressed to you (a request the
-user started toward you, an answer relayed to something you asked, a handoff) without
-consuming any of it, and claim_goal is the catch-up for your own Goals. Bookkeeping ids
-(`operationId`, `idempotencyKey`) are minted here, never asked of the model. Retired
+repeat on reads; contact with nothing to send receives what is addressed to you (a request the
+user started toward you, an answer relayed to something you asked, a handoff, a question you owe) without
+consuming any of it until you acknowledge it (`ackEventIds`), and claim_goal is the catch-up for
+your own Goals. manage_goals creates, edits, assigns, organizes and closes work, a change at a
+time. Bookkeeping (`operationId`, the manage request id, the revision an edit was read at) is
+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**.
@@ -154,7 +156,7 @@ wake channel and reads what is waiting on every nudge. Keep it alive past the te
 with `paigy-listen --install` (launchd on macOS, systemd user unit on Linux;
 `--uninstall` removes it).
 
-The read is `check_replies` — the open Deliveries addressed to this agent — and it
+The read is `receive` (behind `contact({})`) — the open Deliveries addressed to this agent — and it
 **consumes nothing**: no lease, no acknowledgement, and the same read twice returns the
 same list. So the daemon hands the launcher what it found and stops there; claiming is
 the agent's own first act (`claim_goal`), because the daemon shares this machine's
@@ -184,26 +186,39 @@ Goal" from "an empty id".
 PAIGY_ON_WAKE='claude -p "Handle the Paigy work in $PAIGY_WORK — claim_goal first, and read a Goal you do not recognize with get_goal."' \
   npx -y -p @paigy/mcp paigy-listen --install
 
-# Codex (or any CLI harness) — the scalars are enough for a one-liner:
-PAIGY_ON_WAKE='codex exec "Claim Paigy goal $PAIGY_GOAL_ID and continue thread $PAIGY_THREAD_ID. The user said: $PAIGY_TEXT. Reply with contact."' \
-  npx -y -p @paigy/mcp paigy-listen --install
+# Codex terminal session: no custom script and no new conversation.
+# CODEX_THREAD_ID is inherited from the running session.
+npx -y -p @paigy/mcp@latest paigy-listen --brief
 ```
 
 ### A session that starts listening (`listen`, #2265)
 
-Nothing pushes an answer into a session started in a terminal — it waits for that
-session's next `check_replies`. What can reach a running session mid-turn is a watched
-background task, so a terminal session runs `paigy-listen --brief` as its own watched task
-(one human line per event: `Paigy · wake:reply · 2 waiting · lead <deliveryId> on Goal
-<goalId>: "…"`). The `listen` tool is how a session asked to "start listening" gets there
-in one call: it decides and hands over — `listening` (nothing to do), `unpaired` (call
-`onboard`), or `start` with the exact command (this server's own node and `listen.js`,
-`PAIGY_AGENT` and `PAIGY_SESSION_ID` set to this session's slot and id — a session-bound
-identity is refused from any other) for the agent to run as its background task in the
-same turn. It never subscribes, spawns or writes settings. "Already running" is a fact: the
-daemon marks its pid under `~/.paigy/listen/<slot>.pid` while it runs. A session started by
-the Paigy harness (`paigy-harness host` / `run`) needs none of this — its pump types each
-answer in as it lands, and `listen` says so.
+Run `listen` to obtain the exact background command for the current session. For Codex,
+`paigy-listen` reads `CODEX_THREAD_ID`, checks that the installed `codex queue` supports
+`--thread` and `--message`, then queues a wake into that existing conversation. It uses
+argument arrays, never interpolates user text into a shell, and never starts another
+conversation. Two threads in the same folder have separate listener marks and checkpoints.
+Onboarding forwards the thread identifier into the MCP environment; `listen` forwards it
+into the listener command explicitly. Re-running onboarding repairs an existing Paigy allowlist while preserving custom variables; restart the MCP server to inherit the repaired environment. An older slot-wide listener is reported as already receiving until deliberately stopped, so upgrades do not start a second subscriber.
+
+`PAIGY_ON_WAKE` remains an explicit override with its original per-sweep behavior: an
+existing script may ignore boot or timer events. Without a supported adapter, the listener
+still prints events, but reports only `receiving`; a process being alive does not prove it
+can resume an agent. `listening` with a ready adapter means the command is available, and
+`lastQueuedAt` records its last successful exit. Neither claims that the agent read or
+handled a reply. Queue errors are visible in listener output and in `listen` status.
+
+Native Codex wakes coalesce unchanged backlog, including across listener restarts. The listener compares source Entry IDs and accepted Answer timestamps on the bounded list of pending review Goals; its own progress and claims are excluded. A later reply is new evidence even if its words are identical. Failed handoffs remain retryable
+on the existing timer, next nudge or reconnect; discovery never claims or acknowledges
+work. Queue commands are serialized, so a burst becomes one fresh discovery read after
+an in-flight handoff. A command accepted just before a process crash may be queued again;
+the resumed agent must still read and acknowledge actual evidence through Paigy.
+
+A managed Paigy session carries `PAIGY_HARNESS` and keeps its existing delivery pump;
+it does not start another listener. `PAIGY_SESSION_ID` binds API requests and alone does
+not establish harness delivery. Other hosts need a supported wake command or a host that
+actually surfaces watched-task output. Use a session listener for Codex, not `--install`:
+the service is machine-wide and has no current conversation.
 
 `$PAIGY_TEXT` is whatever the user said, expanded inside a shell command — keep it
 quoted, as above. For anything longer than a one-liner, point `PAIGY_ON_WAKE` at a
@@ -218,7 +233,7 @@ codex exec "Paigy goal $PAIGY_GOAL_ID. claim_goal it first. The user said: $PAIG
 ## Stalled work (turn-end hook — Claude Code, Codex, Gemini CLI, Antigravity)
 
 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`): `check_replies` lists it under
+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:
 

package/dist/{chunk-BNMMRKEY.js → chunk-2ROD77AW.js}

@@ -6,7 +6,7 @@ import {
   saveToken,
   setIdentity,
   sleep
-} from "./chunk-PR7ROBN4.js";
+} from "./chunk-EJYXBEWN.js";
 
 // src/identity.ts
 var CLIENT_LABELS = {