@paigy/mcp 0.26.0 → 0.27.0

package/README.md

@@ -141,22 +141,51 @@ wake channel and sweeps on every nudge. Keep it alive past the terminal with
 removes it).
 
 To launch an agent — any agent, not just Claude — when work arrives, set
-`PAIGY_ON_WAKE` to a command before `--install`. The daemon runs it with the swept
-work in `$PAIGY_WORK` (JSON: `replies`, `requests`, `owedCallbacks`); the sweep has
-already claimed the work, so read `$PAIGY_WORK` rather than calling `check_replies`
-again. A request carrying a `contextThreadId` (or an unfamiliar `threadId`) means
-the user is resuming/seeding a past conversation — rehydrate with `get_thread` first.
+`PAIGY_ON_WAKE` to a command before `--install`. The sweep has already claimed the
+work, so the launcher reads it from the environment rather than calling
+`check_replies` again:
+
+| Variable | What it holds |
+| --- | --- |
+| `PAIGY_WORK` | the whole swept payload as JSON (`replies`, `requests`, `owedCallbacks`, `stalled`, `threads`) |
+| `PAIGY_EVENT` | the wake that caused this run — `boot`, `wake:reply`, `cron:callback`… |
+| `PAIGY_THREAD_ID` | the thread to continue on |
+| `PAIGY_NOTIFICATION_ID` | the notification being answered or acted on (unset for an owed callback) |
+| `PAIGY_CONTEXT_THREAD_ID` | a past conversation the user seeded this with — `get_thread` it **first** |
+| `PAIGY_TEXT` | what the user said (or the callback note you owe them), in prose |
+
+Hand `$PAIGY_WORK` to a harness that can read JSON and decide for itself; use the
+scalars for a plain shell launcher that shouldn't need `jq`. They describe **one**
+item — the oldest thread without a turn already in flight — because the queue rail's
+contract is one thread at a time. An absent fact is unset rather than empty, so
+`${PAIGY_CONTEXT_THREAD_ID:-}` distinguishes "no seed" from "seeded with nothing".
 
 ```sh
-# Claude Code:
+# Claude Code — hand it everything and let it plan:
 PAIGY_ON_WAKE='claude -p "Handle the Paigy work in $PAIGY_WORK — rehydrate threads you do not recognize via get_thread first."' \
   npx -y -p @paigy/mcp paigy-listen --install
 
-# Codex (or any CLI harness) works the same way:
-PAIGY_ON_WAKE='codex exec "Handle the Paigy work in $PAIGY_WORK ..."' \
+# Codex (or any CLI harness) — the scalars are enough for a one-liner:
+PAIGY_ON_WAKE='codex exec "Continue Paigy thread $PAIGY_THREAD_ID. The user said: $PAIGY_TEXT. Call get_thread on it first if you do not recognize it, then reply with contact."' \
   npx -y -p @paigy/mcp paigy-listen --install
 ```
 
+`$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
+script and branch on `$PAIGY_EVENT` there:
+
+```sh
+#!/bin/sh
+# ~/.paigy/on-wake.sh — chmod +x, then PAIGY_ON_WAKE=~/.paigy/on-wake.sh
+seed=""
+[ -n "${PAIGY_CONTEXT_THREAD_ID:-}" ] && seed="It continues thread $PAIGY_CONTEXT_THREAD_ID — get_thread that first."
+
+case "$PAIGY_EVENT" in
+  cron:callback*) codex exec "You owe the user a callback on thread $PAIGY_THREAD_ID: $PAIGY_TEXT. Deliver it with contact." ;;
+  *)              codex exec "Paigy thread $PAIGY_THREAD_ID. The user said: $PAIGY_TEXT. $seed Reply with contact when done." ;;
+esac
+```
+
 ## Statusline (Claude Code)
 
 `paigy-statusline` prints a one-line connection status — the account's session

package/dist/{chunk-KAEJRPN5.js → chunk-47E77CDG.js}

@@ -212,7 +212,11 @@ var UserAnswerSchema = z.discriminatedUnion("kind", [
   z.object({ kind: z.literal("turns"), turns: z.array(TurnSchema).min(1) })
 ]);
 var IntentSchema = z.object({
-  kind: z.enum(["defer", "delegate", "channel", "question"]),
+  // The full vocabulary the bot's mapper emits (mapper.INTENT_KINDS) — the schema lagged
+  // it by two ("detail", "feedback"), and because the settle handler parsed the array
+  // all-or-nothing, ONE feedback act silently dropped EVERY intent on the call,
+  // questions included. Found auditing five calls' stored feedback, 2026-08-01.
+  kind: z.enum(["defer", "delegate", "channel", "question", "detail", "feedback", "command"]),
   detail: z.string(),
   /** Landed defer (#397): the MCP parses common spoken forms ("in 20 minutes",
    *  "after lunch") against the agent machine's clock — the user's — and attaches
@@ -382,8 +386,19 @@ var AgendaTurnSchema = z.object({
   question: z.string().min(1).nullable(),
   /** True on the one turn carrying the agent's own declared question. */
   asks: z.boolean().optional(),
+  /** The claim this turn belongs to (#781) — the RETURN identity: answers route by it.
+   *  Absent on a single-claim plan (the session's own claim) and on shared context turns,
+   *  which route nothing. */
+  claimId: z.string().optional(),
+  /** The claim's voice key (#462) — the OUTBOUND identity, audible who-is-asking. */
+  voice: z.string().optional(),
   select: SelectShapeSchema.optional(),
-  options: z.array(OptionSchema.omit({ id: true })).optional()
+  options: z.array(OptionSchema.omit({ id: true })).optional(),
+  /** The seat was satisfied by the call's own ACCOUNT (replan-design.md, user_info): the
+   *  caller already answered this claim in an earlier utterance, quoted here VERBATIM —
+   *  the bot speaks the turn's short confirmation, posts these words as the claim's
+   *  answer, and never re-asks. Grounded at parse time: an invented settle is #796. */
+  settle: z.string().optional()
 });
 var InboxItemSchema = z.object({
   id: z.string(),

package/dist/{chunk-BZPE2ZFE.js → chunk-QXPLQKIM.js}

@@ -1,6 +1,6 @@
 import {
   AGENT_NAME
-} from "./chunk-B7SCZUYX.js";
+} from "./chunk-VCEFF2VA.js";
 
 // src/clients.ts
 import { execFile } from "child_process";

package/dist/{chunk-B7SCZUYX.js → chunk-VCEFF2VA.js}

@@ -2573,7 +2573,11 @@ var UserAnswerSchema = z.discriminatedUnion("kind", [
   z.object({ kind: z.literal("turns"), turns: z.array(TurnSchema).min(1) })
 ]);
 var IntentSchema = z.object({
-  kind: z.enum(["defer", "delegate", "channel", "question"]),
+  // The full vocabulary the bot's mapper emits (mapper.INTENT_KINDS) — the schema lagged
+  // it by two ("detail", "feedback"), and because the settle handler parsed the array
+  // all-or-nothing, ONE feedback act silently dropped EVERY intent on the call,
+  // questions included. Found auditing five calls' stored feedback, 2026-08-01.
+  kind: z.enum(["defer", "delegate", "channel", "question", "detail", "feedback", "command"]),
   detail: z.string(),
   /** Landed defer (#397): the MCP parses common spoken forms ("in 20 minutes",
    *  "after lunch") against the agent machine's clock — the user's — and attaches
@@ -2743,8 +2747,19 @@ var AgendaTurnSchema = z.object({
   question: z.string().min(1).nullable(),
   /** True on the one turn carrying the agent's own declared question. */
   asks: z.boolean().optional(),
+  /** The claim this turn belongs to (#781) — the RETURN identity: answers route by it.
+   *  Absent on a single-claim plan (the session's own claim) and on shared context turns,
+   *  which route nothing. */
+  claimId: z.string().optional(),
+  /** The claim's voice key (#462) — the OUTBOUND identity, audible who-is-asking. */
+  voice: z.string().optional(),
   select: SelectShapeSchema.optional(),
-  options: z.array(OptionSchema.omit({ id: true })).optional()
+  options: z.array(OptionSchema.omit({ id: true })).optional(),
+  /** The seat was satisfied by the call's own ACCOUNT (replan-design.md, user_info): the
+   *  caller already answered this claim in an earlier utterance, quoted here VERBATIM —
+   *  the bot speaks the turn's short confirmation, posts these words as the claim's
+   *  answer, and never re-asks. Grounded at parse time: an invented settle is #796. */
+  settle: z.string().optional()
 });
 var InboxItemSchema = z.object({
   id: z.string(),
@@ -3739,6 +3754,7 @@ async function pollAnswer(notificationId) {
   const item = await res.json();
   return item.type === "idle" ? item : decryptItem(item);
 }
+var AWAIT_WINDOW_MS = 45e3;
 var _partialSeen = /* @__PURE__ */ new Map();
 async function pollPartials(notificationId) {
   const token = readToken();
@@ -3760,11 +3776,12 @@ async function pollPartials(notificationId) {
 }
 async function awaitReply(notificationId, opts = {}) {
   const intervalMs = opts.intervalMs ?? 5e3;
-  const windowMs = opts.windowMs ?? 3e5;
+  const windowMs = opts.windowMs ?? AWAIT_WINDOW_MS;
   const doSleep = opts.sleep ?? sleep2;
   const now = opts.now ?? Date.now;
   const start = now();
   while (true) {
+    if (opts.signal?.aborted) return { type: "idle" };
     const item = await pollAnswer(notificationId);
     if (item.type !== "idle") return item;
     const partial = await pollPartials(notificationId);
@@ -3820,6 +3837,15 @@ async function checkReplies() {
     })
   };
 }
+async function answerCallerQuestion(notificationId, answer) {
+  const res = ensureAuthed(await reach(`${BACKEND_URL}/api/voice/session-answer`, {
+    method: "POST",
+    headers: { "content-type": "application/json", authorization: `Bearer ${readToken()}` },
+    body: JSON.stringify({ notificationId, answer })
+  }));
+  if (!res.ok) throw new Error(`answer_caller_question failed: ${res.status} ${await res.text()}`);
+  return await res.json();
+}
 async function setTaskState(notificationId, state) {
   const res = ensureAuthed(await reach(`${BACKEND_URL}/api/notify/${notificationId}/state`, {
     method: "PATCH",
@@ -3888,6 +3914,7 @@ export {
   getThread,
   searchThreads,
   checkReplies,
+  answerCallerQuestion,
   setTaskState,
   registerDelivery,
   scheduleCallback,

package/dist/index.js

@@ -1,13 +1,13 @@
 #!/usr/bin/env node
 import {
   HandoffSchema
-} from "./chunk-KAEJRPN5.js";
+} from "./chunk-47E77CDG.js";
 import {
   PAIGY_TOOL_IDS,
   autoConfigureClients,
   claudeInstallHint,
   enablePaigyTools
-} from "./chunk-BZPE2ZFE.js";
+} from "./chunk-QXPLQKIM.js";
 import {
   clearSurface,
   writeSurface
@@ -17,6 +17,7 @@ import {
   ScheduleCallbackSchema,
   SetTaskStateSchema,
   UnpairedError,
+  answerCallerQuestion,
   awaitReply,
   checkReplies,
   deleteKeyFile,
@@ -39,7 +40,7 @@ import {
   sleep,
   startE2ee,
   submitNotification
-} from "./chunk-B7SCZUYX.js";
+} from "./chunk-VCEFF2VA.js";
 
 // src/index.ts
 import { Server } from "@modelcontextprotocol/sdk/server/index.js";
@@ -220,8 +221,12 @@ function clearPairing(deviceCode) {
 
 // src/index.ts
 var AwaitReplySchema = z.object({
-  notificationId: z.string().describe("The notificationId returned by contact \u2014 waits for the user's reply to THIS notification only.")
+  notificationId: z.string().describe("The notificationId returned by contact \u2014 waits for the user's reply to THIS notification only."),
+  maxWaitSeconds: z.number().int().min(5).max(300).optional().describe(
+    "How long to hold this ONE call before returning { type:'idle' } so you can loop. Default 45 \u2014 safely under the 60s cap most MCP hosts put on a single tool call. Raise it only if you know your host allows longer; a value past the cap means the call is killed and you get nothing."
+  )
 });
+var JOIN_CAP_MS = 45e3;
 var PairSchema = z.object({
   device_code: z.string().optional().describe("Omit to start pairing (returns an approval link to show the user). Pass the device_code from that first call to finish, once the user has approved.")
 });
@@ -238,6 +243,10 @@ var SetTaskStateToolSchema = z.object({
   notificationId: z.string(),
   state: SetTaskStateSchema.shape.state
 });
+var AnswerCallerQuestionSchema = z.object({
+  notificationId: z.string().describe("The notification whose call carried the caller's question \u2014 from the partial turn or the settled reply."),
+  answer: z.string().min(1).max(1500).describe("The answer, as one or two short SPOKEN sentences \u2014 it may be read aloud on the live call.")
+});
 function detectGit() {
   const run = (cmd) => {
     try {
@@ -319,7 +328,7 @@ function renderPairOutcome(outcome, device_code) {
           text: JSON.stringify({
             status: "pending",
             device_code,
-            message: "Still awaiting approval. Call pair again with this device_code to keep waiting."
+            message: "Still awaiting approval \u2014 the user hasn't entered the code yet. Call pair 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."
           })
         }]
       };
@@ -381,7 +390,7 @@ server.setRequestHandler(ListToolsRequestSchema, async () => {
     },
     {
       name: "await_reply",
-      description: "Wait for the user's reply to a specific notification you sent (pass the notificationId from contact). This is how you wait for your answer in-context. Polls ~5 min; returns { type:'reply', answer } when they respond, { type:'remind', remindInSeconds } on snooze (ScheduleWakeup then await_reply again), or { type:'idle' } (timed out this window, no answer yet). While your contact is being handled on a LIVE call, you may receive { type:'partial', inFlight:true, turn } results: what the user said to each turn, as they say it. Use partials to PREPARE \u2014 fetch the data, draft the thing, warm the build \u2014 never to act irreversibly: the user can still revise any of them until the final reply arrives. Partial = intelligence, settled = authorization. If a partial's acts carry a question aimed at you and you know the answer, call contact on the SAME threadId right away \u2014 the caller hears your answer on the same call instead of waiting for a callback. Keep calling await_reply until you get the final reply \u2014 THAT one is the decision. On idle, if this is genuinely still blocking you and you have nothing else useful to do meanwhile, just call await_reply again immediately \u2014 keep looping. This is how you actually deliver on the point of calling: the user steps away for a while and comes back to find you'd already continued the moment they answered, not idle waiting to be checked on. Don't give up after one window. Only stop looping to do other work (and check back later), or after an unreasonably long stretch (tens of minutes to hours) worth telling the user about instead. Scoped to that one notification \u2014 it NEVER returns replies meant for other notifications, so concurrent contact calls don't cross. A CALL answer can come back as {kind:'turns', turns:[{prompt,reply}]} \u2014 the ordered log of that call. Read turns[0].reply as the user's main instruction. Usually that's the only turn; if there are more (e.g. an end-of-call 'call me back when it's done / I have a blocking question'), read each one in order as a further follow-up instruction, not a single combined one. If they asked for a callback, re-engage in the SAME thread (contact with the reply's threadId) when the task is done or you hit a blocker \u2014 waiting:'hard' for a blocker, waiting:'none' for done. Paigy has no scheduler; the callback is yours to send (use ScheduleWakeup/cron for timing). A call-mapped answer may carry `intents` \u2014 next steps the user attached, each { kind, detail } with detail quoting their words. ACT on them, don't just read them: 'defer' (\"call me after lunch\") \u2192 register it NOW with schedule_callback \u2014 when the intent carries `dueInSeconds` (Paigy pre-parsed the spoken time against the user's clock) pass it straight through; otherwise derive it from the detail yourself \u2014 then follow up on the same thread; 'delegate' (\"you pick\") \u2192 make the call yourself and tell them what you chose; 'channel' (\"text me next time\") \u2192 honor it on your next contact (channel:'message'); 'question' (an open question aimed back at you that the call couldn't answer) \u2192 you OWE them the answer \u2014 work it out and follow up on the same thread without being asked, the call deliberately skipped \"should I call you back?\" because the follow-up is implied. `transcript` is the user's raw words behind a shaped answer \u2014 read it for hedges and conditions (\"yes, IF tests pass\") before acting. If your ask declared `points`, the reply carries `covered` \u2014 the points actually addressed. Compare against what you declared: a missing point is STILL unanswered \u2014 re-ask it (contact on the same threadId) or proceed knowingly partial; never treat a partial answer as complete.",
+      description: "Wait for the user's reply to a specific notification you sent (pass the notificationId from contact). This is how you wait for your answer in-context. Polls ~45s per call \u2014 deliberately under the 60s cap most hosts put on a single tool call, so it ALWAYS returns you something (raise it with maxWaitSeconds only if you know your host allows longer). Returns { type:'reply', answer } when they respond, { type:'remind', remindInSeconds } on snooze (ScheduleWakeup then await_reply again), or { type:'idle' } (this window ended, no answer yet). While your contact is being handled on a LIVE call, you may receive { type:'partial', inFlight:true, turn } results: what the user said to each turn, as they say it. Use partials to PREPARE \u2014 fetch the data, draft the thing, warm the build \u2014 never to act irreversibly: the user can still revise any of them until the final reply arrives. Partial = intelligence, settled = authorization. If a partial's acts carry a question aimed at you and you know the answer, call contact on the SAME threadId right away \u2014 the caller hears your answer on the same call instead of waiting for a callback. Keep calling await_reply until you get the final reply \u2014 THAT one is the decision. On idle, if this is genuinely still blocking you and you have nothing else useful to do meanwhile, just call await_reply again immediately \u2014 keep looping. This is how you actually deliver on the point of calling: the user steps away for a while and comes back to find you'd already continued the moment they answered, not idle waiting to be checked on. Don't give up after one window. Only stop looping to do other work (and check back later), or after an unreasonably long stretch (tens of minutes to hours) worth telling the user about instead. Scoped to that one notification \u2014 it NEVER returns replies meant for other notifications, so concurrent contact calls don't cross. A CALL answer can come back as {kind:'turns', turns:[{prompt,reply}]} \u2014 the ordered log of that call. Read turns[0].reply as the user's main instruction. Usually that's the only turn; if there are more (e.g. an end-of-call 'call me back when it's done / I have a blocking question'), read each one in order as a further follow-up instruction, not a single combined one. If they asked for a callback, re-engage in the SAME thread (contact with the reply's threadId) when the task is done or you hit a blocker \u2014 waiting:'hard' for a blocker, waiting:'none' for done. Paigy has no scheduler; the callback is yours to send (use ScheduleWakeup/cron for timing). A call-mapped answer may carry `intents` \u2014 next steps the user attached, each { kind, detail } with detail quoting their words. ACT on them, don't just read them: 'defer' (\"call me after lunch\") \u2192 register it NOW with schedule_callback \u2014 when the intent carries `dueInSeconds` (Paigy pre-parsed the spoken time against the user's clock) pass it straight through; otherwise derive it from the detail yourself \u2014 then follow up on the same thread; 'delegate' (\"you pick\") \u2192 make the call yourself and tell them what you chose; 'channel' (\"text me next time\") \u2192 honor it on your next contact (channel:'message'); 'question' (an open question aimed back at you that the call couldn't answer) \u2192 you OWE them the answer \u2014 work it out and follow up on the same thread without being asked, the call deliberately skipped \"should I call you back?\" because the follow-up is implied. `transcript` is the user's raw words behind a shaped answer \u2014 read it for hedges and conditions (\"yes, IF tests pass\") before acting. If your ask declared `points`, the reply carries `covered` \u2014 the points actually addressed. Compare against what you declared: a missing point is STILL unanswered \u2014 re-ask it (contact on the same threadId) or proceed knowingly partial; never treat a partial answer as complete.",
       inputSchema: json(AwaitReplySchema)
     },
     {
@@ -404,6 +413,11 @@ server.setRequestHandler(ListToolsRequestSchema, async () => {
       description: "Report progress on the follow-up work behind ANY notification you own \u2014 a user-initiated request (from check_replies), or your OWN contact question once await_reply/check_replies returns its answer and you start acting on it. Pass that notificationId. THIS is what actually claims/acknowledges a reply or request \u2014 check_replies is a pure read that never consumes anything on its own, so call this as soon as you start engaging with something it returned; otherwise that same item just keeps reappearing forever. States: in_progress (you started working), completed (done), or needs_input (you need more from the user \u2014 usually paired with a contact carrying parentId = the same notificationId you're reporting on). Calling this reliably is also what lets a future session's check_replies surface `stalled` work you (or a crashed/idle prior session) left at in_progress without ever reporting completed.",
       inputSchema: json(SetTaskStateToolSchema)
     },
+    {
+      name: "answer_caller_question",
+      description: "Answer a question the user asked DURING a live call, while they're still on it. When a partial turn or a settled reply carries a `question` intent aimed at you, answer it here immediately: if their call is still live, your answer is spoken to them on that same call (returns live: true). If the call already ended (live: false), send the answer as a threaded contact instead \u2014 never drop it. Short spoken sentences only; this may be read aloud.",
+      inputSchema: json(AnswerCallerQuestionSchema)
+    },
     {
       name: "schedule_callback",
       description: "Promise the user a follow-up you'll keep even if you go idle. Use it when they ask you to report back: trigger 'on_done' (when you finish \u2014 fires when you call set_task_state completed), 'on_blocked' (if you hit a blocker \u2014 fires on set_task_state needs_input), or 'scheduled' with dueInSeconds (e.g. 'remind me in 10 min'). Pass the threadId of the conversation and a short note. Fulfill it by calling contact on that threadId; check_replies re-lists due callbacks until you do.",
@@ -417,9 +431,9 @@ server.setRequestHandler(ListToolsRequestSchema, async () => {
   ];
   return { tools };
 });
-server.setRequestHandler(CallToolRequestSchema, async (request) => {
+server.setRequestHandler(CallToolRequestSchema, async (request, extra) => {
   try {
-    return await handleTool(request);
+    return await handleTool(request, extra?.signal);
   } catch (e) {
     if (e instanceof UnpairedError) return pairStartResult(await startPairing(suggestedAgentName()));
     throw e;
@@ -444,14 +458,14 @@ function suggestedAgentName() {
   if (!raw) return void 0;
   return CLIENT_LABELS[raw.toLowerCase()] ?? raw.replace(/[-_]+/g, " ").replace(/\b\w/g, (c) => c.toUpperCase());
 }
-async function handleTool(request) {
+async function handleTool(request, signal) {
   switch (request.params.name) {
     case "pair": {
       const { device_code } = PairSchema.parse(request.params.arguments ?? {});
       if (!device_code) {
         return pairStartResult(await startPairing(suggestedAgentName()));
       }
-      const capMs = 9e4;
+      const capMs = JOIN_CAP_MS;
       const outcome = await joinBackgroundPair(device_code, capMs) ?? await resolvePairing(device_code, capMs);
       return renderPairOutcome(outcome, device_code);
     }
@@ -510,8 +524,11 @@ async function handleTool(request) {
       return { content: [{ type: "text", text: JSON.stringify(result) }] };
     }
     case "await_reply": {
-      const { notificationId } = AwaitReplySchema.parse(request.params.arguments);
-      const item = await awaitReply(notificationId);
+      const { notificationId, maxWaitSeconds } = AwaitReplySchema.parse(request.params.arguments);
+      const item = await awaitReply(notificationId, {
+        ...maxWaitSeconds !== void 0 ? { windowMs: maxWaitSeconds * 1e3 } : {},
+        ...signal ? { signal } : {}
+      });
       return { content: [{ type: "text", text: JSON.stringify(item) }] };
     }
     case "check_replies": {
@@ -526,6 +543,14 @@ async function handleTool(request) {
       const { q } = SearchThreadsSchema.parse(request.params.arguments);
       return { content: [{ type: "text", text: JSON.stringify(await searchThreads(q)) }] };
     }
+    case "answer_caller_question": {
+      const { notificationId, answer } = AnswerCallerQuestionSchema.parse(request.params.arguments);
+      const result = await answerCallerQuestion(notificationId, answer);
+      return { content: [{ type: "text", text: JSON.stringify({
+        ...result,
+        ...result.live ? {} : { note: "The call already ended \u2014 send this as a threaded contact instead so the answer still reaches them." }
+      }) }] };
+    }
     case "set_task_state": {
       const { notificationId, state } = SetTaskStateToolSchema.parse(request.params.arguments);
       const result = await setTaskState(notificationId, state);

package/dist/listen.js

@@ -2,11 +2,11 @@
 import {
   WAKE_EVENT,
   wakeChannel
-} from "./chunk-KAEJRPN5.js";
+} from "./chunk-47E77CDG.js";
 import {
   checkReplies,
   registerDelivery
-} from "./chunk-B7SCZUYX.js";
+} from "./chunk-VCEFF2VA.js";
 
 // src/listen.ts
 import { createClient } from "@supabase/supabase-js";
@@ -113,6 +113,55 @@ function uninstallService() {
 
 // src/listen.ts
 var emit = (obj) => void process.stdout.write(JSON.stringify(obj) + "\n");
+function answerText(answer) {
+  switch (answer.kind) {
+    case "text":
+      return answer.text;
+    case "option":
+      return answer.label ?? answer.optionId;
+    case "multi":
+    case "ranked":
+      return (answer.labels ?? answer.optionIds).join(", ");
+    case "confirm":
+      return answer.approved ? "approved" : "declined";
+    case "clarify":
+      return answer.chunks.join(" ");
+    // A call log — PAIGY_TEXT is what the USER said, so the bot's prompts stay out
+    // (the full exchange is in PAIGY_WORK for a launcher that wants it).
+    case "turns":
+      return answer.turns.map((t) => t.reply).join(" ");
+    case "ignored":
+      return "";
+  }
+}
+function launchEnv(work, reason) {
+  const env = { PAIGY_WORK: JSON.stringify(work), PAIGY_EVENT: reason };
+  const put = (key, value) => {
+    if (value) env[key] = value;
+  };
+  const lead = work.threads?.find((t) => !t.busy)?.items[0]?.notificationId;
+  const reply = lead ? work.replies.find((r) => r.notificationId === lead) : work.replies[0];
+  const request = lead ? work.requests.find((r) => r.notificationId === lead) : work.requests[0];
+  if (reply) {
+    put("PAIGY_THREAD_ID", reply.threadId);
+    put("PAIGY_NOTIFICATION_ID", reply.notificationId);
+    put("PAIGY_TEXT", answerText(reply.answer));
+    return env;
+  }
+  if (request) {
+    put("PAIGY_THREAD_ID", request.threadId);
+    put("PAIGY_NOTIFICATION_ID", request.notificationId);
+    put("PAIGY_CONTEXT_THREAD_ID", request.contextThreadId);
+    put("PAIGY_TEXT", request.text);
+    return env;
+  }
+  const callback = work.owedCallbacks[0];
+  if (callback) {
+    put("PAIGY_THREAD_ID", callback.threadId);
+    put("PAIGY_TEXT", callback.note);
+  }
+  return env;
+}
 async function sweep(reason) {
   try {
     const work = await checkReplies();
@@ -121,7 +170,7 @@ async function sweep(reason) {
     const inbound = work.replies.length > 0 || work.requests.length > 0;
     const reengage = work.owedCallbacks.length > 0 && (reason === "boot" || reason.includes("callback"));
     if (cmd && (inbound || reengage)) {
-      spawn(cmd, { shell: true, stdio: "inherit", env: { ...process.env, PAIGY_WORK: JSON.stringify(work) } });
+      spawn(cmd, { shell: true, stdio: "inherit", env: { ...process.env, ...launchEnv(work, reason) } });
     }
   } catch (e) {
     emit({ type: "error", reason, message: e.message });
@@ -178,5 +227,6 @@ if (isEntry()) {
   }
 }
 export {
+  launchEnv,
   sweep
 };

package/dist/onboard.js

@@ -3,7 +3,7 @@ import {
   autoConfigureClients,
   claudeInstallHint,
   openBrowser
-} from "./chunk-BZPE2ZFE.js";
+} from "./chunk-QXPLQKIM.js";
 import {
   AGENT_NAME,
   TOKEN_PATH,
@@ -11,7 +11,7 @@ import {
   requestCode,
   saveToken,
   sleep
-} from "./chunk-B7SCZUYX.js";
+} from "./chunk-VCEFF2VA.js";
 
 // src/onboard.ts
 async function main() {

package/dist/statusline.js

@@ -6,7 +6,7 @@ import {
   BACKEND_URL,
   reach,
   readToken
-} from "./chunk-B7SCZUYX.js";
+} from "./chunk-VCEFF2VA.js";
 
 // src/statusline.ts
 import { mkdirSync, readFileSync, realpathSync, writeFileSync } from "fs";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@paigy/mcp",
-  "version": "0.26.0",
+  "version": "0.27.0",
   "description": "Paigy MCP server — a voice inbox for your AI agents. Lets an agent notify a user and await their reply.",
   "license": "MIT",
   "type": "module",
@@ -36,9 +36,9 @@
     "tsup": "^8.3.5",
     "typescript": "^5.7.2",
     "vitest": "^2.1.8",
+    "@paigy/crypto": "0.0.0",
     "@paigy/sdk": "0.1.0",
-    "@paigy/schema": "0.0.0",
-    "@paigy/crypto": "0.0.0"
+    "@paigy/schema": "0.0.0"
   },
   "scripts": {
     "build": "tsup",