@paigy/mcp 0.21.0 → 0.24.0

package/README.md

@@ -15,6 +15,9 @@ The Paigy MCP connects automatically. The first time an agent uses it while
 unpaired, it prompts you to pair — run `/paigy-onboard` (opens your browser to
 approve).
 
+> [!NOTE]
+> If you are installing the plugin inside an active Claude Code session, you must type `/reload-plugins` (or restart the session) afterward so the terminal client starts the MCP server and exposes the new tools to the agent.
+
 ### Or add the MCP directly
 
 No clone needed. Add it to Claude Code (`-s user` = available in every project; drop it for just the current one):
@@ -47,7 +50,20 @@ It talks to the hosted backend by default — no config needed. Set
 
 ### Codex CLI (OpenAI)
 
-Codex speaks MCP, so the same server drops in. Add it (writes `~/.codex/config.toml`):
+Recommended: install the Paigy Codex plugin (MCP configuration plus the Paigy workflow skill):
+
+```bash
+codex plugin marketplace add paigy-ai/mcp --ref main
+codex plugin add paigy@paigy-ai
+```
+
+Then pair your phone:
+
+```bash
+npx -y -p @paigy/mcp@latest paigy-mcp-onboard
+```
+
+Or add the MCP server directly (writes `~/.codex/config.toml`):
 
 ```bash
 codex mcp add paigy --env PAIGY_AGENT=codex -- npx -y @paigy/mcp@latest

package/dist/{chunk-VWQQ3VJF.js → chunk-F4SA2TWM.js}

@@ -2711,6 +2711,9 @@ var UserSettingsSchema = z.object({
    *  must not silently reset this privacy choice. Absent = leave unchanged on
    *  write, 'hosted' on read (see store.ts). */
   voiceMode: z.enum(["hosted", "on_device"]).optional(),
+  /** Opt-in to real-phone (PSTN) calls when the app can't ring. Optional, not
+   *  defaulted — an older client PATCHing the full object must not clobber it. */
+  pstnCalls: z.boolean().optional(),
   /** Account E2EE state (text lane): 'off' (default) = today's plaintext; 'on' =
    *  content is sealed end-to-end between the local agent and the phone. Like
    *  voiceMode, OPTIONAL and NOT defaulted so a stale client PATCHing the full
@@ -2916,6 +2919,32 @@ var SupportRequestSchema = z.object({
   message: z.string().trim().min(1).max(5e3),
   name: z.string().trim().max(120).optional()
 });
+var NotificationFeedbackKindSchema = z.enum([
+  "break_down",
+  // "This should be more than one ask — break it down."
+  "regenerate_options",
+  // "These recommended answers aren't good — give me new ones."
+  "needs_visual",
+  // "There should be a picture or design here."
+  "other"
+  // anything else — the note carries it.
+]);
+var NotificationFeedbackSchema = z.object({
+  notificationId: z.string(),
+  kind: NotificationFeedbackKindSchema,
+  /** Optional free-text elaboration for a preset; required (non-empty) for 'other'. */
+  note: z.string().trim().max(2e3).optional()
+}).superRefine((r, ctx) => {
+  if (r.kind === "other" && !r.note)
+    ctx.addIssue({ code: z.ZodIssueCode.custom, path: ["note"], message: "note is required for 'other' feedback" });
+});
+var FeedbackResolutionSchema = z.enum(["broker_fixed", "sent_to_agent"]);
+var FeedbackOutcomeSchema = z.object({
+  resolution: FeedbackResolutionSchema,
+  transform: TransformSchema,
+  message: z.string(),
+  childIds: z.array(z.string()).optional()
+});
 var WORD_NUMS = {
   a: 1,
   an: 1,
@@ -3243,24 +3272,34 @@ var PROTO = "paigy-pair-v2|sas=24";
 var SAS_BITS = 24;
 var TOKEN_PATH = join(homedir(), ".paigy", "token.json");
 var KEY_PATH = join(homedir(), ".paigy", "key.json");
-function saveToken(token) {
+function readTokenFile() {
+  if (!existsSync(TOKEN_PATH)) return {};
+  try {
+    const parsed = JSON.parse(readFileSync(TOKEN_PATH, "utf8"));
+    if (typeof parsed.access_token === "string") return {};
+    const slots = parsed;
+    delete slots["*"];
+    return slots;
+  } catch {
+    return {};
+  }
+}
+function saveToken(token, agent2 = AGENT_NAME) {
+  const slots = { ...readTokenFile(), [agent2]: token };
   mkdirSync(join(homedir(), ".paigy"), { recursive: true });
-  writeFileSync(TOKEN_PATH, JSON.stringify(token, null, 2) + "\n", { mode: 384 });
+  writeFileSync(TOKEN_PATH, JSON.stringify(slots, null, 2) + "\n", { mode: 384 });
 }
 var sleep = (ms) => new Promise((r) => setTimeout(r, ms));
-function readToken() {
+function readToken(agent2 = AGENT_NAME) {
   if (process.env.PAIGY_TOKEN) return process.env.PAIGY_TOKEN;
-  if (existsSync(TOKEN_PATH)) {
-    try {
-      return JSON.parse(readFileSync(TOKEN_PATH, "utf8")).access_token ?? "";
-    } catch {
-    }
-  }
-  return "";
-}
-function deleteToken() {
-  if (!existsSync(TOKEN_PATH)) return false;
-  rmSync(TOKEN_PATH);
+  return readTokenFile()[agent2]?.access_token ?? "";
+}
+function deleteToken(agent2 = AGENT_NAME) {
+  const slots = readTokenFile();
+  if (!(agent2 in slots)) return false;
+  delete slots[agent2];
+  if (Object.keys(slots).length === 0) rmSync(TOKEN_PATH);
+  else writeFileSync(TOKEN_PATH, JSON.stringify(slots, null, 2) + "\n", { mode: 384 });
   return true;
 }
 async function revokeToken(token) {

package/dist/{chunk-HO3OJHRA.js → chunk-JIQKMDUU.js}

@@ -1,6 +1,6 @@
 import {
   AGENT_NAME
-} from "./chunk-VWQQ3VJF.js";
+} from "./chunk-F4SA2TWM.js";
 
 // src/clients.ts
 import { execFile } from "child_process";
@@ -78,8 +78,14 @@ function autoConfigureClients(skip = AGENT_NAME) {
 }
 function claudeInstallHint(skip = AGENT_NAME) {
   if (skip.startsWith("claude")) return null;
-  if (!existsSync(join(homedir(), ".claude"))) return null;
-  return "Claude Code detected \u2014 to add Paigy there, run /plugin marketplace add paigy-ai/claude then /plugin install paigy (pairing carries over; no need to pair again).";
+  const claudeDir = join(homedir(), ".claude");
+  if (!existsSync(claudeDir)) return null;
+  try {
+    const registry = join(claudeDir, "plugins", "installed_plugins.json");
+    if (existsSync(registry) && readFileSync(registry, "utf8").includes('"paigy@')) return null;
+  } catch {
+  }
+  return "Claude Code detected \u2014 to add Paigy there, run /plugin marketplace add paigy-ai/claude then /plugin install paigy (pairing carries over; no need to pair again). Note: If you run this inside a live session, type /reload-plugins afterward so the agent connects to the new tools.";
 }
 var PAIGY_TOOL_IDS = [
   "mcp__paigy__notify_user",

package/dist/{chunk-SLWESECN.js → chunk-ZLN2C6IY.js}

@@ -422,6 +422,9 @@ var UserSettingsSchema = z.object({
    *  must not silently reset this privacy choice. Absent = leave unchanged on
    *  write, 'hosted' on read (see store.ts). */
   voiceMode: z.enum(["hosted", "on_device"]).optional(),
+  /** Opt-in to real-phone (PSTN) calls when the app can't ring. Optional, not
+   *  defaulted — an older client PATCHing the full object must not clobber it. */
+  pstnCalls: z.boolean().optional(),
   /** Account E2EE state (text lane): 'off' (default) = today's plaintext; 'on' =
    *  content is sealed end-to-end between the local agent and the phone. Like
    *  voiceMode, OPTIONAL and NOT defaulted so a stale client PATCHing the full
@@ -629,6 +632,32 @@ var SupportRequestSchema = z.object({
   message: z.string().trim().min(1).max(5e3),
   name: z.string().trim().max(120).optional()
 });
+var NotificationFeedbackKindSchema = z.enum([
+  "break_down",
+  // "This should be more than one ask — break it down."
+  "regenerate_options",
+  // "These recommended answers aren't good — give me new ones."
+  "needs_visual",
+  // "There should be a picture or design here."
+  "other"
+  // anything else — the note carries it.
+]);
+var NotificationFeedbackSchema = z.object({
+  notificationId: z.string(),
+  kind: NotificationFeedbackKindSchema,
+  /** Optional free-text elaboration for a preset; required (non-empty) for 'other'. */
+  note: z.string().trim().max(2e3).optional()
+}).superRefine((r, ctx) => {
+  if (r.kind === "other" && !r.note)
+    ctx.addIssue({ code: z.ZodIssueCode.custom, path: ["note"], message: "note is required for 'other' feedback" });
+});
+var FeedbackResolutionSchema = z.enum(["broker_fixed", "sent_to_agent"]);
+var FeedbackOutcomeSchema = z.object({
+  resolution: FeedbackResolutionSchema,
+  transform: TransformSchema,
+  message: z.string(),
+  childIds: z.array(z.string()).optional()
+});
 
 export {
   HandoffSchema,

package/dist/index.js

@@ -1,13 +1,13 @@
 #!/usr/bin/env node
 import {
   HandoffSchema
-} from "./chunk-SLWESECN.js";
+} from "./chunk-ZLN2C6IY.js";
 import {
   PAIGY_TOOL_IDS,
   autoConfigureClients,
   claudeInstallHint,
   enablePaigyTools
-} from "./chunk-HO3OJHRA.js";
+} from "./chunk-JIQKMDUU.js";
 import {
   clearSurface,
   writeSurface
@@ -38,7 +38,7 @@ import {
   sleep,
   startE2ee,
   submitNotification
-} from "./chunk-VWQQ3VJF.js";
+} from "./chunk-F4SA2TWM.js";
 
 // src/index.ts
 import { Server } from "@modelcontextprotocol/sdk/server/index.js";
@@ -260,7 +260,7 @@ var server = new Server(
   { name: "paigy", version: "0.0.0" },
   {
     capabilities: { tools: {} },
-    instructions: "On startup, call check_replies once to pick up any replies or pending work you missed while away. A check_replies request whose threadId you don't recognize, or one carrying a contextThreadId, means the user is resuming or seeding a past conversation \u2014 call get_thread on it FIRST and treat the transcript as prior conversation, not new input. To wait for the answer to something you just asked, call await_reply with that notificationId \u2014 it's scoped to that one notification, so it never returns replies meant for other notifications. Use check_replies again only when re-booting or after waiting a long time on something else. Never end a turn that still needs the user without notify_user + await_reply. When you need a decision or input, MATCH the answer shape to the question \u2014 don't default everything to free text, and don't reflexively make everything yes/no. Pick the best tool for the job: yes/no \u2192 select:'confirm'; approve/deny an action \u2192 select:'confirm' + confirmStyle:'approve'; pick one of several \u2192 options + select:'one'; pick several / a subset \u2192 options + select:'many'; rank or prioritize \u2192 options + select:'rank'. Reserve select:'text' (free-form reply only) for plain updates and answers that genuinely can't be structured (the user can always add free text on top of any shape). On a { kind: 'clarify' } reply, see notify_user's own description for how to respond. When urgency is 'call', remember the title + description are spoken aloud \u2014 write them short and conversational, and name things instead of using IDs (e.g. 'the pull request about the agents page', not 'PR #235'). When the user asks you to follow up later \u2014 when you're done, if you're blocked, or at a set time \u2014 record it with schedule_callback so you don't drop it if you go idle. If you're about to start a genuinely long-running or blocking piece of work \u2014 one where the user would otherwise sit and wait \u2014 mention ONCE, in passing, that you can reach them when it's done or if you hit a blocker, instead of them needing to babysit the terminal. Don't offer this for quick tasks, and don't repeat the offer if they've already said yes or no earlier in the conversation. Escalate silence, don't just wait on it: if you notified at a lower urgency (inbox/push/banner) for something that's genuinely blocking real progress, call await_reply up to twice (~5 min each, ~10 min total) \u2014 if it's still idle after that AND the item is genuinely blocking, send a fresh notify_user on the SAME threadId at urgency:'call'. Skip this for anything that isn't truly blocking; a normal question can just sit in the inbox. NEVER go quietly idle while something might still be pending for you: whenever you end a turn with any Paigy notification unanswered (or any chance the user replied through the app while you worked), schedule your own ~2-minute wake-up (harness ScheduleWakeup or equivalent) and call check_replies when it fires; if still nothing, re-schedule and keep looping until resolved or the user says stop. For legibility, always use this exact wording \u2014 reason: 'Paigy idle check \u2014 waiting on <thing>', wake-up prompt: 'Paigy idle check: call check_replies and engage with anything unacknowledged; if idle, re-schedule (~2min).' \u2014 so the user can recognize every idle check at a glance. This self-polling in your own live session (full context intact) is the PRIMARY mechanism; the plugin's Stop hooks are only the dead-session safety net."
+    instructions: "On startup, call check_replies once to pick up any replies or pending work you missed while away. A check_replies request whose threadId you don't recognize, or one carrying a contextThreadId, means the user is resuming or seeding a past conversation \u2014 call get_thread on it FIRST and treat the transcript as prior conversation, not new input. To wait for the answer to something you just asked, call await_reply with that notificationId \u2014 it's scoped to that one notification, so it never returns replies meant for other notifications. Use check_replies again only when re-booting or after waiting a long time on something else. Never end a turn that still needs the user without notify_user + await_reply. When you need a decision or input, MATCH the answer shape to the question \u2014 don't default everything to free text, and don't reflexively make everything yes/no. Pick the best tool for the job: yes/no \u2192 select:'confirm'; approve/deny an action \u2192 select:'confirm' + confirmStyle:'approve'; pick one of several \u2192 options + select:'one'; pick several / a subset \u2192 options + select:'many'; rank or prioritize \u2192 options + select:'rank'. Reserve select:'text' (free-form reply only) for plain updates and answers that genuinely can't be structured (the user can always add free text on top of any shape). On a { kind: 'clarify' } reply, see notify_user's own description for how to respond. When urgency is 'call', remember the title + description are spoken aloud \u2014 write them short and conversational, and name things instead of using IDs (e.g. 'the pull request about the agents page', not 'PR #235'). When the user asks you to follow up later \u2014 when you're done, if you're blocked, or at a set time \u2014 record it with schedule_callback so you don't drop it if you go idle. If you're about to start a genuinely long-running or blocking piece of work \u2014 one where the user would otherwise sit and wait \u2014 mention ONCE, in passing, that you can reach them when it's done or if you hit a blocker, instead of them needing to babysit the terminal. Don't offer this for quick tasks, and don't repeat the offer if they've already said yes or no earlier in the conversation. Escalate silence, don't just wait on it: if you notified at a lower urgency (inbox/push/banner) for something that's genuinely blocking real progress, call await_reply up to twice (~5 min each, ~10 min total) \u2014 if it's still idle after that AND the item is genuinely blocking, re-send notify_user on the SAME threadId at urgency:'call' with the SAME content \u2014 identical content on an existing thread escalates the notification already sitting there instead of creating a second one, so don't reword the title/description just to escalate. Reword only when you genuinely have new information, which correctly becomes a new notification on the thread. Skip this for anything that isn't truly blocking; a normal question can just sit in the inbox. NEVER go quietly idle while something might still be pending for you: whenever you end a turn with any Paigy notification unanswered (or any chance the user replied through the app while you worked), schedule your own ~2-minute wake-up (harness ScheduleWakeup or equivalent) and call check_replies when it fires; if still nothing, re-schedule and keep looping until resolved or the user says stop. For legibility, always use this exact wording \u2014 reason: 'Paigy idle check \u2014 waiting on <thing>', wake-up prompt: 'Paigy idle check: call check_replies and engage with anything unacknowledged; if idle, re-schedule (~2min).' \u2014 so the user can recognize every idle check at a glance. This self-polling in your own live session (full context intact) is the PRIMARY mechanism; the plugin's Stop hooks are only the dead-session safety net."
   }
 );
 server.setRequestHandler(ListToolsRequestSchema, async () => ({
@@ -282,7 +282,7 @@ server.setRequestHandler(ListToolsRequestSchema, async () => ({
     },
     {
       name: "notify_user",
-      description: "Notify the user via Paigy. Returns { notificationId, threadId } \u2014 pass notificationId to await_reply for the answer, threadId to notify_user to continue the conversation. THREADING REPLACES: a threaded follow-up SUPERSEDES your earlier pending items on that thread (they leave the user's inbox; the response reports supersededCount) \u2014 right for updates to one ask, WRONG for a checklist: send parallel to-dos as separate un-threaded notifications. SIMPLEST FORM \u2014 just state what you need: { ask: \"I need to know whether to deploy the auth fix \u2014 tests are green, staging verified\", urgencyHint: 'now'|'soon'|'whenever', needs?: [\"deploy?\", \"keep the flag?\"] }. Paigy's broker derives the title, answer shape, options, and delivery channel for you \u2014 prefer this unless you specifically need to control the exact options/shape. The fully-shaped form below remains available and unchanged (the two are mutually exclusive: send `ask` OR `context`+`select`). FULLY-SHAPED FORM: provide context.title (a specific, non-empty one-line headline \u2014 this is what the user sees first, and what shows on the ring for a call) and context.description (an array of standalone, non-empty detail chunks the user can selectively ask you to expand). Set `urgency`: 'inbox' (default) drops it silently in their inbox; 'push' is a quiet passive notification (no sound); 'banner' sends a time-sensitive banner/lock-screen push (a 'paige') they tap to open \u2014 for when you need them soon-ish but not enough to ring them; 'call' rings their phone now as a voice call \u2014 only when you genuinely need them in the moment (blocked/waiting, time-sensitive). This is the premier use case for Paigy: getting UNBLOCKED so you can keep working, not just reporting that you're stuck. The user started a big task and went to do something else \u2014 the cardinal failure is going idle on one small decision and silently waiting to be checked on, so they come back to find you never actually progressed. Judge urgency by how much WORK IS BLOCKED behind this decision (a lot of dependent downstream work \u2192 call, even if it's a single question), not by how many things happen to be pending \u2014 one blocking decision outweighs five independent low-stakes ones sitting in the inbox. Set `blocking: true` whenever that's the case, independent of `urgency` \u2014 it's what lets Paigy escalate this to a real call later on its own if it goes unanswered, even if you sent it at a lower urgency. Don't set it for things you could work around, defer, or where other useful work exists meanwhile. ON A CALL, your title + description are READ ALOUD by a voice \u2014 write them to be HEARD, not read: keep it short and conversational, front-load the ask, and refer to things BY NAME, not by ID or code (say 'the pull request about the agents page', not 'PR #235'; 'the login-bug ticket', not 'ABC-1234'). Spell out only what's natural to say out loud. MATCH the answer shape to the question \u2014 `select` is required; pick the best tool for the job, not always yes/no. The user can ALWAYS add free text on top of any shape, so structuring loses nothing. Choose `select`: yes/no \u2192 select:'confirm' \u2192 {kind:'confirm', approved:boolean}. Approve/deny an action \u2192 select:'confirm' + confirmStyle:'approve' \u2192 {kind:'confirm', approved:boolean}. Both are answerable right from the banner \u2014 no need to open the app. Pick one of several \u2192 options + select:'one' \u2192 {kind:'option', optionId}. Pick several / a subset \u2192 options + select:'many' \u2192 {kind:'multi', optionIds:[...]}. Rank or prioritize \u2192 options + select:'rank', user taps in preferred order \u2192 {kind:'ranked', optionIds:[...]}. One/many/rank/text all need the user to open the app to answer \u2014 only confirm is answerable straight from the banner. Options carry no ids \u2014 they're assigned by position ('1', '2', \u2026), and the answer's optionId(s) are those positions. For visual choices give each option a sandboxed `html` or an `image` preview (e.g. layout/UI alternatives); use `visuals` for images that set context for the whole question. select:'text' = free-form reply only (plain updates, or answers that genuinely can't be structured). If a reply comes back as {kind:'clarify', chunks:[...]}, the user wants more detail on those chunks \u2014 respond via notify_user with the SAME threadId and an expanded description. Pass `threadId` from a prior notify_user result or an await_reply reply to continue that conversation thread; omit it to start a new one. To follow up on a call (e.g. the user asked you to 'call me back when it's done'), reuse the threadId from that call's reply so it threads as the same conversation.",
+      description: "Notify the user via Paigy. Returns { notificationId, threadId } \u2014 pass notificationId to await_reply for the answer, threadId to notify_user to continue the conversation. THREADING REPLACES: a threaded follow-up SUPERSEDES your earlier pending items on that thread (they leave the user's inbox; the response reports supersededCount) \u2014 right for updates to one ask, WRONG for a checklist: send parallel to-dos as separate un-threaded notifications. A threaded re-send with IDENTICAL content instead escalates the pending ask in place (the response reports escalated: true and returns the SAME notificationId, so any await_reply you already have on it keeps working). SIMPLEST FORM \u2014 just state what you need: { ask: \"I need to know whether to deploy the auth fix \u2014 tests are green, staging verified\", urgencyHint: 'now'|'soon'|'whenever', needs?: [\"deploy?\", \"keep the flag?\"] }. Paigy's broker derives the title, answer shape, options, and delivery channel for you \u2014 prefer this unless you specifically need to control the exact options/shape. The fully-shaped form below remains available and unchanged (the two are mutually exclusive: send `ask` OR `context`+`select`). FULLY-SHAPED FORM: provide context.title (a specific, non-empty one-line headline \u2014 this is what the user sees first, and what shows on the ring for a call) and context.description (an array of standalone, non-empty detail chunks the user can selectively ask you to expand). Set `urgency`: 'inbox' (default) drops it silently in their inbox; 'push' is a quiet passive notification (no sound); 'banner' sends a time-sensitive banner/lock-screen push (a 'paige') they tap to open \u2014 for when you need them soon-ish but not enough to ring them; 'call' rings their phone now as a voice call \u2014 only when you genuinely need them in the moment (blocked/waiting, time-sensitive). This is the premier use case for Paigy: getting UNBLOCKED so you can keep working, not just reporting that you're stuck. The user started a big task and went to do something else \u2014 the cardinal failure is going idle on one small decision and silently waiting to be checked on, so they come back to find you never actually progressed. Judge urgency by how much WORK IS BLOCKED behind this decision (a lot of dependent downstream work \u2192 call, even if it's a single question), not by how many things happen to be pending \u2014 one blocking decision outweighs five independent low-stakes ones sitting in the inbox. Set `blocking: true` whenever that's the case, independent of `urgency` \u2014 it's what lets Paigy escalate this to a real call later on its own if it goes unanswered, even if you sent it at a lower urgency. Don't set it for things you could work around, defer, or where other useful work exists meanwhile. ON A CALL, your title + description are READ ALOUD by a voice \u2014 write them to be HEARD, not read: keep it short and conversational, front-load the ask, and refer to things BY NAME, not by ID or code (say 'the pull request about the agents page', not 'PR #235'; 'the login-bug ticket', not 'ABC-1234'). Spell out only what's natural to say out loud. MATCH the answer shape to the question \u2014 `select` is required; pick the best tool for the job, not always yes/no. The user can ALWAYS add free text on top of any shape, so structuring loses nothing. Choose `select`: yes/no \u2192 select:'confirm' \u2192 {kind:'confirm', approved:boolean}. Approve/deny an action \u2192 select:'confirm' + confirmStyle:'approve' \u2192 {kind:'confirm', approved:boolean}. Both are answerable right from the banner \u2014 no need to open the app. Pick one of several \u2192 options + select:'one' \u2192 {kind:'option', optionId}. Pick several / a subset \u2192 options + select:'many' \u2192 {kind:'multi', optionIds:[...]}. Rank or prioritize \u2192 options + select:'rank', user taps in preferred order \u2192 {kind:'ranked', optionIds:[...]}. One/many/rank/text all need the user to open the app to answer \u2014 only confirm is answerable straight from the banner. Options carry no ids \u2014 they're assigned by position ('1', '2', \u2026), and the answer's optionId(s) are those positions. For visual choices give each option a sandboxed `html` or an `image` preview (e.g. layout/UI alternatives); use `visuals` for images that set context for the whole question. select:'text' = free-form reply only (plain updates, or answers that genuinely can't be structured). If a reply comes back as {kind:'clarify', chunks:[...]}, the user wants more detail on those chunks \u2014 respond via notify_user with the SAME threadId and an expanded description. Pass `threadId` from a prior notify_user result or an await_reply reply to continue that conversation thread; omit it to start a new one. To follow up on a call (e.g. the user asked you to 'call me back when it's done'), reuse the threadId from that call's reply so it threads as the same conversation.",
       inputSchema: json(NotifyRequestSchema)
     },
     {

package/dist/listen.js

@@ -2,11 +2,11 @@
 import {
   WAKE_EVENT,
   wakeChannel
-} from "./chunk-SLWESECN.js";
+} from "./chunk-ZLN2C6IY.js";
 import {
   checkReplies,
   registerDelivery
-} from "./chunk-VWQQ3VJF.js";
+} from "./chunk-F4SA2TWM.js";
 
 // src/listen.ts
 import { createClient } from "@supabase/supabase-js";

package/dist/onboard.js

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

package/dist/statusline.js

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@paigy/mcp",
-  "version": "0.21.0",
+  "version": "0.24.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/schema": "0.0.0",
-    "@paigy/sdk": "0.1.0"
+    "@paigy/sdk": "0.1.0",
+    "@paigy/crypto": "0.0.0"
   },
   "scripts": {
     "build": "tsup",