switchroom 0.14.45 → 0.14.47

package/telegram-plugin/gateway/gateway.ts

@@ -2240,6 +2240,47 @@ function resumeReactionAfterVerdict(): void {
     ?.setThinking()
 }
 
+/**
+ * The recipient set for a permission card (the initial Approve/Deny card
+ * AND the post-verdict resume message — they MUST route identically, so
+ * both go through this one helper).
+ *
+ * Turn-initiated (the normal case — a permission gate fires mid-tool-use
+ * with an active turn): send to the ORIGINATING chat+thread. For a
+ * supergroup-owned agent working in a forum topic that is the supergroup +
+ * the topic, so the card lands IN the topic the operator asked from (e.g.
+ * marko's "CRM (Brevo)" topic) — not the operator's DM. For a DM agent the
+ * originating chat IS the operator's DM (thread-less), unchanged.
+ *
+ * No active turn (cron / background / a swept turn at TTL): fall back to the
+ * configured operator DMs (`allowFrom`), thread-stripped via
+ * `topicForRecipient` so a DM never gets a `message_thread_id` (the 400
+ * "message thread not found" → auto-deny wedge, #2096).
+ *
+ * Before this helper the INITIAL card emitter iterated `allowFrom`
+ * unconditionally, so a supergroup card could only ever reach operator DMs —
+ * the topic chat id is never in `allowFrom`. The resume message already
+ * routed correctly; the card now matches it (marko, 2026-06-03).
+ */
+function resolvePermissionCardTargets(): Array<{ chatId: string; threadId: number | undefined }> {
+  const turn = currentTurn
+  if (turn != null) {
+    return [{ chatId: turn.sessionChatId, threadId: turn.sessionThreadId }]
+  }
+  const sg = resolveAgentSupergroupChatId()
+  const topic = resolveAgentOutboundTopic({
+    kind: 'permission',
+    turnInitiated: false,
+    originThreadId: undefined,
+  })
+  // allowFrom is normally operator DMs — attach the topic only to a
+  // recipient that owns it (the supergroup), never a DM (marko wedge).
+  return loadAccess().allowFrom.map(chatId => ({
+    chatId,
+    threadId: topicForRecipient({ recipientChatId: chatId, resolvedTopic: topic, supergroupChatId: sg }),
+  }))
+}
+
 /**
  * Post the agent-voiced "got your verdict — continuing" message the
  * instant the operator answers a permission card. Travels right beside
@@ -2269,24 +2310,7 @@ function postPermissionResumeMessage(opts: {
     action: opts.action,
     timeoutMinutes: opts.timeoutMinutes,
   })
-  const turn = currentTurn
-  const targets: Array<{ chatId: string; threadId: number | undefined }> =
-    turn != null
-      ? [{ chatId: turn.sessionChatId, threadId: turn.sessionThreadId }]
-      : (() => {
-          const sg = resolveAgentSupergroupChatId()
-          const topic = resolveAgentOutboundTopic({
-            kind: 'permission',
-            turnInitiated: false,
-            originThreadId: undefined,
-          })
-          // allowFrom is normally operator DMs — attach the topic only to a
-          // recipient that owns it (the supergroup), never a DM (marko wedge).
-          return loadAccess().allowFrom.map(chatId => ({
-            chatId,
-            threadId: topicForRecipient({ recipientChatId: chatId, resolvedTopic: topic, supergroupChatId: sg }),
-          }))
-        })()
+  const targets = resolvePermissionCardTargets()
   for (const { chatId, threadId } of targets) {
     // allow-raw-bot-api: wrapped in swallowingApiCall (retry policy); thread-aware send
     void swallowingApiCall(
@@ -2913,6 +2937,10 @@ interface PendingVaultRequestSave {
   chat_id: string
   /** Card message id (filled in after we send the card). */
   card_message_id?: number
+  /** Supergroup forum topic the agent was working in when it requested the
+   *  save — carried into the save-outcome inbound so the resumed reply lands
+   *  back in that topic, not General. */
+  threadId?: number
   /** Currently-suggested slug; may be renamed by the user. */
   key: string
   /** Storage shape — 'string' (default) or 'binary'. */
@@ -2954,6 +2982,10 @@ interface PendingVaultRequestAccess {
   chat_id: string
   /** Card message id (filled in after we send the card). */
   card_message_id?: number
+  /** Supergroup forum topic the agent was working in when it requested (the
+   *  card's originating thread). Carried into the grant-outcome inbound so the
+   *  resumed reply lands back in that topic, not General. */
+  threadId?: number
   /** Vault key the agent wants to read. */
   key: string
   /** 'read' (default) or 'write'. */
@@ -4657,7 +4689,6 @@ const ipcServer: IpcServer = createIpcServer({
   onPermissionRequest(_client: IpcClient, msg: PermissionRequestForward) {
     const { requestId, toolName, description, inputPreview } = msg
     pendingPermissions.set(requestId, { tool_name: toolName, description, input_preview: inputPreview, startedAt: Date.now() })
-    const access = loadAccess()
     // Natural-language card body — a plain sentence ("Gymbro wants to
     // edit: supplement-log.md" + a why-line), never a raw tool id.
     // The operator sees what is being requested and why at a glance.
@@ -4677,42 +4708,34 @@ const ipcServer: IpcServer = createIpcServer({
     // two-button row only.
     const showAlways = resolveScopedAllowChoices(toolName, inputPreview) != null
     const keyboard = buildPermissionActionRow(requestId, showAlways)
-    // PR4b emitter sweep — supergroup-mode permission card routing.
-    // Per CPO #3 the design is "turn-initiated requests follow the
-    // conversation topic; background requests go to admin alias."
-    // Permission requests come from the bridge mid-tool-use, so they
-    // are always turn-initiated in practice — the currently active
-    // turn's sessionThreadId is the originating topic. Fall back to
-    // admin alias when no active turn (cron / background path).
-    // Fleet-shared / DM agents see `undefined` → no
-    // `message_thread_id` is added → behavior unchanged.
-    // currentTurn is the singleton "claude is currently on this turn"
-    // pointer — per Framing 1 / PR3b scope-discovery, claude
-    // serializes so there's exactly one (or zero) active turn at any
-    // moment. When set, the permission request is in-flight for that
-    // turn and follows the originating topic.
+    // Route the card to the SAME place the post-verdict resume message
+    // lands (resolvePermissionCardTargets): the ORIGINATING chat+topic when
+    // there's an active turn — so a supergroup agent's card appears IN the
+    // topic the operator asked from (marko's "CRM (Brevo)"), not the
+    // operator DM — else the configured operator DMs, thread-stripped. The
+    // old code iterated `allowFrom` unconditionally, so a supergroup card
+    // could only ever reach operator DMs (the topic chat id is never in
+    // `allowFrom`) (marko, 2026-06-03).
     const activeTurn = currentTurn
-    const permTopic = resolveAgentOutboundTopic({
-      kind: 'permission',
-      turnInitiated: activeTurn != null,
-      originThreadId: activeTurn?.sessionThreadId,
-    })
-    const permSupergroup = resolveAgentSupergroupChatId()
-    for (const chat_id of access.allowFrom) {
-      // parse_mode=HTML pairs with formatPermissionCardBody (#1790)
-      // so the <b>/<i> tags render as formatting.
-      // The resolved topic is valid only in the agent's supergroup — attach
-      // it ONLY when this recipient IS that supergroup. allowFrom DMs get the
-      // card thread-less; attaching a topic to a DM yields 400 "message thread
-      // not found" → card never arrives → auto-deny → wedge (marko 2026-06-02).
-      const permThread = topicForRecipient({ recipientChatId: chat_id, resolvedTopic: permTopic, supergroupChatId: permSupergroup })
-      // allow-raw-bot-api: permission-request keyboard fan-out; topic-aware opts
-      void bot.api.sendMessage(chat_id, text, {
-        parse_mode: 'HTML',
-        reply_markup: keyboard,
-        ...(permThread != null ? { message_thread_id: permThread } : {}),
-      }).catch(e => {
-        process.stderr.write(`telegram gateway: permission_request send to ${chat_id} failed: ${e}\n`)
+    const targets = resolvePermissionCardTargets()
+    for (const { chatId, threadId } of targets) {
+      // parse_mode=HTML pairs with formatPermissionCardBody (#1790) so the
+      // <b>/<i> tags render. retryWithThreadFallback: if the topic was
+      // deleted/recreated (stale thread id → 400 "message thread not
+      // found"), re-send thread-less into the main chat so the card still
+      // ARRIVES rather than vanishing → 10-min TTL auto-deny → wedge.
+      // allow-raw-bot-api: wrapped in retryWithThreadFallback (retry policy); topic-aware send
+      void retryWithThreadFallback<{ message_id: number }>(
+        robustApiCall,
+        (tid) =>
+          bot.api.sendMessage(chatId, text, {
+            parse_mode: 'HTML',
+            reply_markup: keyboard,
+            ...(tid != null ? { message_thread_id: tid } : {}),
+          }),
+        { threadId, chat_id: chatId, verb: 'permission_request' },
+      ).catch(e => {
+        process.stderr.write(`telegram gateway: permission_request send to ${chatId} failed: ${e}\n`)
       })
     }
     // Park the turn's status reaction on 🙏 (awaiting your tap) and
@@ -7080,6 +7103,8 @@ async function executeVaultRequestSave(args: Record<string, unknown>): Promise<{
   // crashing the tool call.
   const text = renderVaultRequestSaveCard(pending, agentSlug)
   const threadId = args.message_thread_id != null ? Number(args.message_thread_id) : undefined
+  // Remember the agent's working topic so the save-outcome inbound resumes in it.
+  if (threadId != null) pending.threadId = threadId
   const sent = await retryWithThreadFallback<{ message_id: number }>(
     robustApiCall,
     (tid) =>
@@ -7120,12 +7145,16 @@ interface PendingSecretRequest {
   reason?: string
   staged_at: number
   card_message_id?: number
+  /** Supergroup forum topic the agent was working in — carried into the
+   *  provide/decline/fail outcome inbounds so the resumed reply lands back
+   *  in that topic, not General. */
+  threadId?: number
 }
 // stageId -> request (lives until tapped or TTL).
 const pendingSecretRequests = new Map<string, PendingSecretRequest>()
 // chat_id -> the armed capture: the operator's NEXT message in this chat is
 // the value for `key`. Set when [Provide securely] is tapped.
-interface ArmedSecretCapture { key: string; agent: string; stageId: string; armed_at: number }
+interface ArmedSecretCapture { key: string; agent: string; stageId: string; armed_at: number; threadId?: number }
 const armedSecretCaptures = new Map<string, ArmedSecretCapture>()
 const PENDING_SECRET_REQUEST_TTL_MS = 30 * 60_000 // card lifetime
 const ARMED_SECRET_CAPTURE_TTL_MS = 10 * 60_000   // window to send the value after tapping
@@ -7194,6 +7223,8 @@ async function executeRequestSecret(args: Record<string, unknown>): Promise<{ co
 
   const text = renderSecretRequestCard(pending)
   const threadId = args.message_thread_id != null ? Number(args.message_thread_id) : undefined
+  // Remember the agent's working topic so the provide/decline/fail inbound resumes in it.
+  if (threadId != null) pending.threadId = threadId
   const sent = await retryWithThreadFallback<{ message_id: number }>(
     robustApiCall,
     (tid) =>
@@ -7269,12 +7300,19 @@ async function captureProvidedSecret(
     const failMsg: InboundMessage = {
       type: 'inbound',
       chatId: chat_id,
+      ...(armed.threadId != null ? { threadId: armed.threadId } : {}),
       messageId: fts,
       user: 'vault-broker',
       userId: 0,
       ts: fts,
       text: `⚠️ The secret you requested for \`vault:${armed.key}\` could NOT be saved (vault write failed). Do not assume it is available; tell the operator or try request_secret again.`,
-      meta: { source: 'secret_provide_failed', agent: armed.agent, key: armed.key, stage_id: armed.stageId },
+      meta: {
+        source: 'secret_provide_failed',
+        agent: armed.agent,
+        ...(armed.threadId != null ? { message_thread_id: String(armed.threadId) } : {}),
+        key: armed.key,
+        stage_id: armed.stageId,
+      },
     }
     const fdelivered = ipcServer.sendToAgent(armed.agent, failMsg)
     if (fdelivered) markClaudeBusyForInbound(failMsg)
@@ -7294,6 +7332,7 @@ async function captureProvidedSecret(
   const synthetic: InboundMessage = {
     type: 'inbound',
     chatId: chat_id,
+    ...(armed.threadId != null ? { threadId: armed.threadId } : {}),
     messageId: ts,
     user: 'vault-broker',
     userId: 0,
@@ -7305,6 +7344,7 @@ async function captureProvidedSecret(
     meta: {
       source: 'secret_provided',
       agent: armed.agent,
+      ...(armed.threadId != null ? { message_thread_id: String(armed.threadId) } : {}),
       key: armed.key,
       stage_id: armed.stageId,
     },
@@ -7345,6 +7385,7 @@ async function handleSecretRequestCallback(ctx: Context, data: string): Promise<
       agent: pending.agent,
       stageId,
       armed_at: Date.now(),
+      ...(pending.threadId != null ? { threadId: pending.threadId } : {}),
     })
     await ctx.answerCallbackQuery({ text: 'Send the value now — it auto-deletes.' }).catch(() => {})
     if (pending.card_message_id != null) {
@@ -7377,12 +7418,19 @@ async function handleSecretRequestCallback(ctx: Context, data: string): Promise<
     const synthetic: InboundMessage = {
       type: 'inbound',
       chatId: pending.chat_id,
+      ...(pending.threadId != null ? { threadId: pending.threadId } : {}),
       messageId: ts,
       user: 'vault-broker',
       userId: 0,
       ts,
       text: `🚫 Operator declined your request for \`vault:${pending.key}\`. Proceed without it or ask how they'd like to handle the task.`,
-      meta: { source: 'secret_declined', agent: pending.agent, key: pending.key, stage_id: stageId },
+      meta: {
+        source: 'secret_declined',
+        agent: pending.agent,
+        ...(pending.threadId != null ? { message_thread_id: String(pending.threadId) } : {}),
+        key: pending.key,
+        stage_id: stageId,
+      },
     }
     const delivered = ipcServer.sendToAgent(pending.agent, synthetic)
     if (delivered) markClaudeBusyForInbound(synthetic)
@@ -7530,6 +7578,8 @@ async function executeVaultRequestAccess(args: Record<string, unknown>): Promise
 
   const text = renderVaultRequestAccessCard(pending)
   const threadId = args.message_thread_id != null ? Number(args.message_thread_id) : undefined
+  // Remember the agent's working topic so the grant-outcome inbound resumes in it.
+  if (threadId != null) pending.threadId = threadId
   // #1075: deleted-topic safe — fall back to main chat.
   const sent = await retryWithThreadFallback<{ message_id: number }>(
     robustApiCall,
@@ -14023,6 +14073,7 @@ async function performVaultAccessApproval(
       scope: pending.scope,
       chat_id: pending.chat_id,
       ttl_seconds: pending.ttl_seconds,
+      ...(pending.threadId != null ? { threadId: pending.threadId } : {}),
     },
     grantId: id,
     stageId,
@@ -14104,6 +14155,7 @@ async function handleVaultRequestAccessCallback(ctx: Context, data: string): Pro
         scope: pending.scope,
         chat_id: pending.chat_id,
         ttl_seconds: pending.ttl_seconds,
+        ...(pending.threadId != null ? { threadId: pending.threadId } : {}),
       },
       stageId,
       operatorId: senderId,
@@ -14278,7 +14330,12 @@ async function handleVaultRequestSaveCallback(ctx: Context, data: string): Promi
     // tool returned "waiting for operator", the turn ended, and a
     // Discard left the agent silently idle forever.
     const discardInbound = buildVaultSaveDiscardedInbound({
-      ctx: { agent: pending.agent, key: pending.key, chat_id: pending.chat_id },
+      ctx: {
+        agent: pending.agent,
+        key: pending.key,
+        chat_id: pending.chat_id,
+        ...(pending.threadId != null ? { threadId: pending.threadId } : {}),
+      },
       stageId,
       operatorId: senderId,
     })
@@ -14401,7 +14458,12 @@ async function handleVaultRequestSaveCallback(ctx: Context, data: string): Promi
       const failReason =
         (write.output || 'vault write error').split('\n')[0]!.slice(0, 200)
       const failInbound = buildVaultSaveFailedInbound({
-        ctx: { agent: pending.agent, key: pending.key, chat_id: pending.chat_id },
+        ctx: {
+          agent: pending.agent,
+          key: pending.key,
+          chat_id: pending.chat_id,
+          ...(pending.threadId != null ? { threadId: pending.threadId } : {}),
+        },
         stageId,
         operatorId: senderId,
         reason: failReason,
@@ -14432,7 +14494,12 @@ async function handleVaultRequestSaveCallback(ctx: Context, data: string): Promi
     // task that was blocked on this credential (symmetric with the
     // vra: approve path; buffered if the bridge is mid-reconnect).
     const okInbound = buildVaultSaveCompletedInbound({
-      ctx: { agent: pending.agent, key: pending.key, chat_id: pending.chat_id },
+      ctx: {
+        agent: pending.agent,
+        key: pending.key,
+        chat_id: pending.chat_id,
+        ...(pending.threadId != null ? { threadId: pending.threadId } : {}),
+      },
       stageId,
       operatorId: senderId,
     })

package/telegram-plugin/gateway/vault-grant-inbound-builders.ts

@@ -34,6 +34,10 @@ export interface VaultGrantInboundContext {
   chat_id: string
   /** Seconds. For approved grants; ignored for deny. */
   ttl_seconds: number
+  /** Supergroup forum topic (message_thread_id) the agent was working in
+   *  when it requested the credential — so the resumed turn's reply lands
+   *  back in that topic, not General. Undefined for DM / non-topic requests. */
+  threadId?: number
 }
 
 /**
@@ -62,6 +66,7 @@ export function buildVaultGrantApprovedInbound(opts: {
   return {
     type: 'inbound',
     chatId: opts.ctx.chat_id,
+    ...(opts.ctx.threadId != null ? { threadId: opts.ctx.threadId } : {}),
     messageId: ts, // synthetic — no Telegram message id exists
     user: 'vault-broker',
     userId: 0,
@@ -76,6 +81,7 @@ export function buildVaultGrantApprovedInbound(opts: {
     meta: {
       source: 'vault_grant_approved',
       agent: opts.ctx.agent,
+      ...(opts.ctx.threadId != null ? { message_thread_id: String(opts.ctx.threadId) } : {}),
       key: opts.ctx.key,
       scope: opts.ctx.scope,
       grant_id: opts.grantId,
@@ -103,6 +109,7 @@ export function buildVaultGrantDeniedInbound(opts: {
   return {
     type: 'inbound',
     chatId: opts.ctx.chat_id,
+    ...(opts.ctx.threadId != null ? { threadId: opts.ctx.threadId } : {}),
     messageId: ts,
     user: 'vault-broker',
     userId: 0,
@@ -116,6 +123,7 @@ export function buildVaultGrantDeniedInbound(opts: {
     meta: {
       source: 'vault_grant_denied',
       agent: opts.ctx.agent,
+      ...(opts.ctx.threadId != null ? { message_thread_id: String(opts.ctx.threadId) } : {}),
       key: opts.ctx.key,
       scope: opts.ctx.scope,
       stage_id: opts.stageId,
@@ -133,6 +141,9 @@ export interface VaultSaveInboundContext {
   /** Telegram chat the save card lived in — keeps the synthesized
    *  resume-turn associated with the originating conversation. */
   chat_id: string
+  /** Supergroup forum topic the agent was working in when it requested the
+   *  save — so the resumed reply lands in that topic, not General. */
+  threadId?: number
 }
 
 /**
@@ -154,6 +165,7 @@ export function buildVaultSaveCompletedInbound(opts: {
   return {
     type: 'inbound',
     chatId: opts.ctx.chat_id,
+    ...(opts.ctx.threadId != null ? { threadId: opts.ctx.threadId } : {}),
     messageId: ts,
     user: 'vault-broker',
     userId: 0,
@@ -165,6 +177,7 @@ export function buildVaultSaveCompletedInbound(opts: {
     meta: {
       source: 'vault_save_completed',
       agent: opts.ctx.agent,
+      ...(opts.ctx.threadId != null ? { message_thread_id: String(opts.ctx.threadId) } : {}),
       key: opts.ctx.key,
       stage_id: opts.stageId,
       operator_id: opts.operatorId,
@@ -187,6 +200,7 @@ export function buildVaultSaveFailedInbound(opts: {
   return {
     type: 'inbound',
     chatId: opts.ctx.chat_id,
+    ...(opts.ctx.threadId != null ? { threadId: opts.ctx.threadId } : {}),
     messageId: ts,
     user: 'vault-broker',
     userId: 0,
@@ -200,6 +214,7 @@ export function buildVaultSaveFailedInbound(opts: {
     meta: {
       source: 'vault_save_failed',
       agent: opts.ctx.agent,
+      ...(opts.ctx.threadId != null ? { message_thread_id: String(opts.ctx.threadId) } : {}),
       key: opts.ctx.key,
       stage_id: opts.stageId,
       operator_id: opts.operatorId,
@@ -221,6 +236,7 @@ export function buildVaultSaveDiscardedInbound(opts: {
   return {
     type: 'inbound',
     chatId: opts.ctx.chat_id,
+    ...(opts.ctx.threadId != null ? { threadId: opts.ctx.threadId } : {}),
     messageId: ts,
     user: 'vault-broker',
     userId: 0,
@@ -234,6 +250,7 @@ export function buildVaultSaveDiscardedInbound(opts: {
     meta: {
       source: 'vault_save_discarded',
       agent: opts.ctx.agent,
+      ...(opts.ctx.threadId != null ? { message_thread_id: String(opts.ctx.threadId) } : {}),
       key: opts.ctx.key,
       stage_id: opts.stageId,
       operator_id: opts.operatorId,

package/telegram-plugin/permission-title.ts

@@ -19,10 +19,21 @@
 
 import { basename } from "node:path";
 import { prettyMcpServer, type ScopeOption } from "./permission-rule.js";
+import { redact } from "./secret-detect/redact.js";
 
 const COMMAND_TITLE_MAX = 48;
 const DESCRIPTION_LINE_MAX = 240;
 
+/** HTTP methods the generic REST-wrapper MCP tools (brevo/meta/postiz/… via
+ *  rest-server.mjs) expose as verbs — uppercased on the card so the operator
+ *  reads "POST /smtp/email" as an API write, not "post". */
+const HTTP_VERBS = new Set(["get", "post", "put", "patch", "delete", "head"]);
+/** Keys that, on a REST-style MCP input, name the resource/endpoint. */
+const RESOURCE_KEYS = ["path", "endpoint", "url", "resource", "route"];
+const ARG_SUMMARY_MAX_KEYS = 4; // how many payload keys to surface on the card
+const ARG_VALUE_MAX = 40; // per-value truncation in the arg-summary line
+const ARG_SUMMARY_LINE_MAX = 180; // total cap for the arg-summary line
+
 /**
  * Human verb-phrases for switchroom-managed MCP tools. The raw
  * `mcp__<server>__<tool>` name is operator-hostile. Phrases are written
@@ -104,6 +115,14 @@ export function formatPermissionCardBody(opts: {
       : `why: <i>not provided</i>`,
   );
 
+  // Third line (REST-wrapper MCP writes only): a redaction-safe summary of
+  // the payload so the operator can see WHAT is being sent, not just the
+  // endpoint — e.g. "↳ to: lisa@…, subject: Priority access…".
+  const argSummary = mcpArgSummary(opts.toolName, opts.inputPreview);
+  if (argSummary) {
+    lines.push(`↳ <i>${escapeTgHtml(argSummary)}</i>`);
+  }
+
   return lines.join("\n");
 }
 
@@ -171,7 +190,6 @@ function naturalMcpAction(
   toolName: string,
   input: Record<string, unknown> | null,
 ): string {
-  void input;
   const parts = toolName.split("__");
   const server = parts.length >= 2 ? parts[1]! : "";
   const curated = MCP_TOOL_DESCRIPTIONS[toolName];
@@ -183,6 +201,15 @@ function naturalMcpAction(
   }
   if (parts.length >= 3) {
     const verb = parts.slice(2).join("__").replace(/_/g, " ");
+    // External REST-wrapper tools (brevo/meta/postiz/…) take a `path`. Name
+    // the endpoint so "post (Brevo)" becomes "POST /smtp/email (Brevo)" —
+    // the operator can see WHICH resource is being written, not just that
+    // *something* is. Internal servers + tools without a resource key keep
+    // the plain verb phrasing.
+    if (!INTERNAL_MCP_SERVERS.has(server)) {
+      const resourcePhrase = restResourcePhrase(server, verb, input);
+      if (resourcePhrase) return resourcePhrase;
+    }
     return INTERNAL_MCP_SERVERS.has(server)
       ? verb
       : `${verb} (${prettyMcpServer(server)})`;
@@ -190,6 +217,78 @@ function naturalMcpAction(
   return `use ${toolName}`;
 }
 
+/**
+ * For a REST-wrapper MCP call ({ path, body?, query? }), build the action
+ * phrase "<VERB> <path> (<Server>)" — e.g. "POST /smtp/email (Brevo)". The
+ * path is redaction-passed + length-capped before display. Returns null
+ * when the input carries no recognizable resource key (caller falls back to
+ * the plain verb phrasing).
+ */
+function restResourcePhrase(
+  server: string,
+  verb: string,
+  input: Record<string, unknown> | null,
+): string | null {
+  if (!input) return null;
+  let path: string | null = null;
+  for (const key of RESOURCE_KEYS) {
+    path = readString(input, key);
+    if (path) break;
+  }
+  if (!path) return null;
+  const v = HTTP_VERBS.has(verb.toLowerCase()) ? verb.toUpperCase() : verb;
+  const shownPath = truncate(redact(path), COMMAND_TITLE_MAX);
+  return `${v} ${shownPath} (${prettyMcpServer(server)})`;
+}
+
+/**
+ * A compact, redaction-safe one-line summary of a REST-wrapper MCP call's
+ * payload ({ body } for writes, { query } for reads) — the third card line.
+ * Shows up to {@link ARG_SUMMARY_MAX_KEYS} payload keys with short, masked
+ * scalar values ("to: lisa@…, subject: Priority access…"); nested
+ * objects/arrays surface as the bare key name (no value dump — avoids
+ * leaking PII/secrets and oversized blobs). Every value passes through
+ * `redact()` so an API key in the payload is masked, never surfaced.
+ * Returns null when there's nothing meaningful to show.
+ */
+function mcpArgSummary(
+  toolName: string,
+  inputPreview: string | undefined,
+): string | null {
+  if (!toolName.startsWith("mcp__")) return null;
+  // Internal servers (agent-config / hostd / hindsight / telegram) use flat
+  // input schemas, not the REST `body`/`query` convention — and we don't
+  // endpoint-enrich their title line either, so keep the summary line off
+  // them too (redact() still runs, so this is intent-match, not a leak fix).
+  const server = toolName.split("__")[1] ?? "";
+  if (INTERNAL_MCP_SERVERS.has(server)) return null;
+  const input = parseInput(inputPreview);
+  if (!input) return null;
+  const payload = input.body ?? input.query;
+  if (!payload || typeof payload !== "object" || Array.isArray(payload)) {
+    return null;
+  }
+  const parts: string[] = [];
+  for (const [key, value] of Object.entries(payload as Record<string, unknown>)) {
+    if (parts.length >= ARG_SUMMARY_MAX_KEYS) {
+      parts.push("…");
+      break;
+    }
+    if (value == null) continue;
+    if (typeof value === "object") {
+      parts.push(key); // nested object/array → key name only, never dumped
+      continue;
+    }
+    const shown = truncate(redact(String(value)), ARG_VALUE_MAX);
+    parts.push(`${key}: ${shown}`);
+  }
+  if (parts.length === 0) return null;
+  const joined = parts.join(", ");
+  return joined.length > ARG_SUMMARY_LINE_MAX
+    ? joined.slice(0, ARG_SUMMARY_LINE_MAX - 1) + "…"
+    : joined;
+}
+
 /**
  * Confirmation phrase describing a grant that just landed, derived from
  * the *scope option the operator chose* — so an always-allow's breadth

package/telegram-plugin/tests/permission-card-routing.test.ts

@@ -0,0 +1,77 @@
+/**
+ * Structural pin for permission-card topic routing.
+ *
+ * The bug (marko, 2026-06-03): the INITIAL Approve/Deny card emitter
+ * (`onPermissionRequest`) iterated `access.allowFrom` unconditionally as its
+ * recipient set. For a supergroup-owned agent, `allowFrom` holds only the
+ * operator DM user-ids — the supergroup chat id is never in it — so a
+ * permission card raised from a forum topic could ONLY ever land in the
+ * operator's DM, never in the topic the operator asked from. The
+ * post-verdict resume message already routed correctly (to the turn's
+ * originating chat+thread); the card did not.
+ *
+ * The fix routes BOTH the card and the resume through one shared helper,
+ * `resolvePermissionCardTargets()`, so they can't drift: turn-initiated →
+ * the originating chat+topic; no active turn → operator DMs, thread-stripped
+ * via topicForRecipient (the DM-thread 400 / auto-deny guard, #2096).
+ *
+ * gateway.ts is not unit-importable (top-level side effects), so this is a
+ * source-text pin in the same style as permission-verdict-resume-guard.ts.
+ * The routing *logic* (topicForRecipient / resolveAgentOutboundTopic) is
+ * unit-tested in src/telegram/topic-router.test.ts; the end-to-end
+ * "card lands in the topic" is covered by the supergroup UAT. This guards
+ * the wiring: that the card uses the shared helper and never reverts to the
+ * raw allowFrom fan-out.
+ */
+
+import { describe, it, expect } from 'vitest'
+import { readFileSync } from 'node:fs'
+import { fileURLToPath } from 'node:url'
+import { dirname, resolve } from 'node:path'
+
+const __dirname = dirname(fileURLToPath(import.meta.url))
+const GATEWAY_SRC = readFileSync(
+  resolve(__dirname, '..', 'gateway', 'gateway.ts'),
+  'utf8',
+)
+
+/** Slice the body of the `onPermissionRequest` IPC handler — from its header
+ *  to the next handler method (`onHeartbeat`). */
+function onPermissionRequestBody(): string {
+  const start = GATEWAY_SRC.indexOf('onPermissionRequest(')
+  expect(start).toBeGreaterThan(-1)
+  const rest = GATEWAY_SRC.slice(start)
+  const end = rest.indexOf('onHeartbeat(')
+  expect(end).toBeGreaterThan(-1)
+  return rest.slice(0, end)
+}
+
+describe('permission card routing', () => {
+  it('the shared target helper exists', () => {
+    expect(
+      /function\s+resolvePermissionCardTargets\s*\(/.test(GATEWAY_SRC),
+    ).toBe(true)
+  })
+
+  it('the initial card emitter routes via resolvePermissionCardTargets()', () => {
+    expect(onPermissionRequestBody()).toContain('resolvePermissionCardTargets()')
+  })
+
+  it('the initial card emitter no longer iterates access.allowFrom directly (the bug shape)', () => {
+    // The raw fan-out loop is what sent supergroup cards to operator DMs.
+    expect(onPermissionRequestBody()).not.toMatch(
+      /for\s*\(\s*const\s+chat_id\s+of\s+access\.allowFrom\s*\)/,
+    )
+  })
+
+  it('the card send is wrapped in retryWithThreadFallback (stale-topic → thread-less, not a silent drop)', () => {
+    expect(onPermissionRequestBody()).toContain('retryWithThreadFallback')
+  })
+
+  it('the resume message uses the SAME helper, so card + resume cannot drift', () => {
+    const start = GATEWAY_SRC.indexOf('function postPermissionResumeMessage(')
+    expect(start).toBeGreaterThan(-1)
+    const body = GATEWAY_SRC.slice(start, start + 1400)
+    expect(body).toContain('resolvePermissionCardTargets()')
+  })
+})