@llblab/pi-kit 0.36.2 → 0.37.0

package/node_modules/@llblab/pi-telegram/dist/lib/extension.js

@@ -80,7 +80,7 @@ const telegramBusProtocolIdentity = Bus.createTelegramCurrentBusProtocolIdentity
 export default function (pi) {
     Skills.registerTelegramSkillDiscovery(pi);
     const piRuntime = Pi.createExtensionApiRuntimePorts(pi);
-    const { getActiveTools, getCommands, getThinkingLevel, sendUserMessage, registerCommand, setActiveTools, setModel, setThinkingLevel, } = piRuntime;
+    const { getActiveTools, getCommands, getThinkingLevel, sendUserMessage, setActiveTools, setModel, setThinkingLevel, } = piRuntime;
     const bridgeRuntime = Runtime.createTelegramBridgeRuntime();
     const runtimeDiagnostics = Logging.createTelegramRuntimeDiagnosticsRuntime({
         sharedFile: true,
@@ -242,7 +242,6 @@ export default function (pi) {
         captureAuthority: captureTelegramStateAuthority,
     });
     const sessionActionAssembly = Commands.createTelegramSessionActionAssembly({
-        registerCommand,
         sendUserMessage,
         store: threadStore,
         getProfileName: configStore.getActiveProfileName,
@@ -1093,6 +1092,25 @@ export default function (pi) {
         },
         getAdmissionScope: getTelegramUpdateAdmissionScope,
         getAdmissionJournalBinding: getTelegramQueueJournalBinding,
+        getCommandReplyTarget(message) {
+            if (message.chat.type !== "private" ||
+                "business_connection_id" in message ||
+                !Updates.getTelegramUpdateExecutionFence(message) ||
+                lockRuntime.owns())
+                return undefined;
+            Updates.assertTelegramUpdateExecutionCurrent(message);
+            const binding = resolveTelegramFollowerJournalBinding();
+            const target = telegramBusFollowerRegistrationState.getTarget();
+            if (!telegramBusFollowerRegistrationState.isRegistered() ||
+                !binding ||
+                binding.recoveryKey !==
+                    followerAdmissionLifecycleRuntime.getJournalBindingKey() ||
+                !target ||
+                (threadStore.getBotState().threadMode === "enabled" &&
+                    target.threadId === undefined))
+                throw new Error("Telegram command reply lost its registered recipient.");
+            return { ...target };
+        },
         beginCommandEffectWork: publicationRuntime.beginWork,
         getMessageOwnership: messageOwnershipRuntime.getForwardOwnership,
         recordMessageOwnership: messageOwnershipRuntime.recordRouted,
@@ -1400,15 +1418,6 @@ export default function (pi) {
                     return binding.hasAuthority?.() === true;
                 });
             },
-            recoverRejectedRecipientTarget(error) {
-                const rejected = error instanceof TelegramApi.TelegramApiFollowerNotAllowedError
-                    ? error.requestTarget
-                    : undefined;
-                const current = telegramBusFollowerRegistrationState.getTarget();
-                return rejected && current?.threadId !== undefined
-                    ? { rejected, current: { chatId: current.chatId, threadId: current.threadId } }
-                    : undefined;
-            },
             prepareUpdateForExecution(update) {
                 return BusFollower.prepareTelegramBusFollowerJournaledUpdateForExecution(update, textGroupRuntime.prepareForwardedMessage);
             },
@@ -2283,9 +2292,9 @@ export default function (pi) {
             }
         },
     }.reset);
-    sessionActionsRuntime.register();
     Bindings.registerTelegramCommandsAndTools({
         pi,
+        handleInternalAction: sessionActionsRuntime.handleInternalAction,
         agentDir: Paths.resolveAgentDir(),
         configStore,
         persistConfig: persistTelegramConfigWithSync,

package/node_modules/@llblab/pi-telegram/dist/lib/menu-settings.d.ts

@@ -52,7 +52,7 @@ export interface TelegramSettingsMenuCallbackDeps extends TelegramSettingsMutati
     sectionRegistry?: TelegramSectionRegistry;
 }
 export interface TelegramSettingsMenuRuntime<TContext> {
-    openSettingsMenu: (chatId: number, replyToMessageId: number, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
+    openSettingsMenu: (chatId: number, replyToMessageId: number | undefined, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
     handleCallbackQuery: (query: {
         id: string;
         data?: string;

package/node_modules/@llblab/pi-telegram/dist/lib/menu.d.ts

@@ -87,7 +87,7 @@ export interface TelegramMenuActionRuntimeDeps<TContext, TModel extends MenuMode
     storeModelMenuState: (state: TelegramModelMenuState<TModel>) => void;
     isIdle: (ctx: TContext) => boolean;
     canOfferInFlightModelSwitch: (ctx: TContext) => boolean;
-    sendTextReply: (chatId: number, replyToMessageId: number, text: string, options?: {
+    sendTextReply: (chatId: number, replyToMessageId: number | undefined, text: string, options?: {
         target?: {
             chatId: number;
             threadId?: number;
@@ -102,9 +102,9 @@ export interface TelegramMenuActionRuntime<TContext, TModel extends MenuModel =
     updateModelMenuMessage: (state: TelegramModelMenuState<TModel>, ctx: TContext) => Promise<void>;
     updateThinkingMenuMessage: (state: TelegramModelMenuState<TModel>, ctx: TContext) => Promise<void>;
     updateStatusMessage: (state: TelegramModelMenuState<TModel>, ctx: TContext) => Promise<void>;
-    sendStatusMessage: (chatId: number, replyToMessageId: number, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
-    openModelMenu: (chatId: number, replyToMessageId: number, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
-    openThinkingMenu: (chatId: number, replyToMessageId: number, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
+    sendStatusMessage: (chatId: number, replyToMessageId: number | undefined, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
+    openModelMenu: (chatId: number, replyToMessageId: number | undefined, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
+    openThinkingMenu: (chatId: number, replyToMessageId: number | undefined, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
 }
 export declare function handleTelegramMenuCallbackEntry(callbackQueryId: string, data: string | undefined, state: TelegramModelMenuState | undefined, deps: TelegramMenuCallbackEntryDeps): Promise<void>;
 export declare function handleStoredTelegramMenuCallback<TModel extends MenuModel = MenuModel>(query: MenuCallbackQuery, deps: StoredTelegramMenuCallbackDeps<TModel>): Promise<void>;

package/node_modules/@llblab/pi-telegram/dist/lib/routing.d.ts

@@ -174,6 +174,7 @@ export interface TelegramInboundRouteRuntimeDeps<TMessage extends TelegramRouted
     getCurrentInstanceId?: () => string | undefined;
     getAdmissionScope?: () => string | undefined;
     getAdmissionJournalBinding?: () => string | undefined;
+    getCommandReplyTarget?: Commands.TelegramCommandTargetRuntimeDeps<TContext>["getReplyTarget"];
     getMessageOwnership?: Updates.TelegramMessageOwnershipLookup;
     getTargetOwnership?: Updates.TelegramTargetOwnershipLookup;
     recordMessageOwnership?: Updates.TelegramMessageOwnershipRecorder;
@@ -256,7 +257,7 @@ export interface TelegramInboundRouteRuntimeDeps<TMessage extends TelegramRouted
     isVoiceReplyActive?: () => boolean;
     updateSettingsMenuMessage?: (state: Menu.TelegramModelMenuState<TModel>, ctx: TContext) => Promise<void>;
     openQueueMenu: (chatId: number, replyToMessageId: number, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
-    openSettingsMenu?: (chatId: number, replyToMessageId: number, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
+    openSettingsMenu?: (chatId: number, replyToMessageId: number | undefined, ctx: TContext, threadId?: number, options?: Pick<TelegramApiCallOptions, "assertAuthority">) => Promise<void>;
     settingsMenuCallbackHandler?: (query: TCallbackQuery, ctx: TContext) => Promise<boolean>;
     queueMenuCallbackHandler: (query: TCallbackQuery, ctx: TContext) => Promise<boolean>;
     buttonActionStore?: OutboundHandlers.TelegramButtonActionStore;
@@ -303,7 +304,7 @@ export interface TelegramInboundRouteRuntimeDeps<TMessage extends TelegramRouted
     }) => Promise<string | undefined>;
     /** Starts the animated placeholder on an answered guest inline message. */
     startGuestPlaceholder?: (inlineMessageId: string) => void;
-    sendTextReply: (chatId: number, replyToMessageId: number, text: string, options?: {
+    sendTextReply: (chatId: number, replyToMessageId: number | undefined, text: string, options?: {
         parseMode?: "HTML";
         target?: Queue.TelegramQueueTarget;
         assertAuthority?: TelegramApiCallOptions["assertAuthority"];

package/node_modules/@llblab/pi-telegram/dist/lib/routing.js

@@ -7139,6 +7139,7 @@ export function createTelegramInboundRouteRuntime(deps) {
         appendControlItem: deps.queueMutationRuntime.append,
         getAdmissionScope: deps.getAdmissionScope,
         getAdmissionJournalBinding: deps.getAdmissionJournalBinding,
+        getReplyTarget: deps.getCommandReplyTarget,
         onControlQueued: (message, receipt) => reportQueueAdmission([message], [receipt]),
         showStatus: deps.menuActions.sendStatusMessage,
         openModelMenu: deps.menuActions.openModelMenu,

package/node_modules/@llblab/pi-telegram/dist/lib/telegram-api.d.ts

@@ -505,16 +505,18 @@ export declare class TelegramApiStaleTargetError extends Error {
         threadId: number;
     });
 }
-/** The leader's exact refusal of a follower API call outside that follower's own Thread; carries only the requested target. */
+/** A follower API refusal; legacy text alone does not prove the request was rejected before execution. */
 export declare class TelegramApiFollowerNotAllowedError extends Error {
     readonly requestTarget: {
         chatId: number;
         threadId: number;
     } | undefined;
+    /** Present only after a structured pre-execution refusal matches the requested API method. */
+    readonly rejectedRequestMethod: string | undefined;
     constructor(message: string, requestTarget?: {
         chatId: number;
         threadId: number;
-    });
+    }, rejectedRequestMethod?: string);
 }
 export declare function getTelegramApiErrorRequestTarget(error: unknown): {
     chatId: number;

package/node_modules/@llblab/pi-telegram/dist/lib/telegram-api.js

@@ -338,13 +338,16 @@ export class TelegramApiStaleTargetError extends Error {
         this.requestTarget = { ...requestTarget };
     }
 }
-/** The leader's exact refusal of a follower API call outside that follower's own Thread; carries only the requested target. */
+/** A follower API refusal; legacy text alone does not prove the request was rejected before execution. */
 export class TelegramApiFollowerNotAllowedError extends Error {
     requestTarget;
-    constructor(message, requestTarget) {
+    /** Present only after a structured pre-execution refusal matches the requested API method. */
+    rejectedRequestMethod;
+    constructor(message, requestTarget, rejectedRequestMethod) {
         super(message);
         this.name = "TelegramApiFollowerNotAllowedError";
         this.requestTarget = requestTarget ? { ...requestTarget } : undefined;
+        this.rejectedRequestMethod = rejectedRequestMethod;
     }
 }
 export function getTelegramApiErrorRequestTarget(error) {
@@ -1036,6 +1039,7 @@ export function createTelegramBridgeApiRuntime(deps) {
     const chatActionMinIntervalMs = Math.max(0, deps.chatActionMinIntervalMs ?? 2_000);
     const chatActionMaxGates = Math.max(1, deps.chatActionMaxGates ?? 256);
     const chatActionGates = new Map();
+    // Pin shared cooldowns until every concurrent Thread settles; this state never owns their sends.
     const chatActionChatGates = new Map();
     const getChatActionKeys = (method, body) => {
         if (method !== "sendChatAction")
@@ -1066,7 +1070,7 @@ export function createTelegramBridgeApiRuntime(deps) {
                 }
             }
             for (const [key, candidate] of chatActionChatGates) {
-                if (!candidate.inFlight && nowMs >= candidate.notBeforeMs) {
+                if (candidate.pendingRequests === 0 && nowMs >= candidate.notBeforeMs) {
                     chatActionChatGates.delete(key);
                 }
             }
@@ -1082,13 +1086,11 @@ export function createTelegramBridgeApiRuntime(deps) {
                 if (chatActionChatGates.size >= chatActionMaxGates) {
                     return true;
                 }
-                chatGate = { notBeforeMs: 0 };
+                chatGate = { pendingRequests: 0, notBeforeMs: 0 };
                 chatActionChatGates.set(chatActionKeys.chat, chatGate);
             }
             if (gate.inFlight)
                 return (await gate.inFlight);
-            if (chatGate.inFlight)
-                return true;
             if (nowMs < gate.notBeforeMs || nowMs < chatGate.notBeforeMs) {
                 return true;
             }
@@ -1124,11 +1126,10 @@ export function createTelegramBridgeApiRuntime(deps) {
                 .finally(() => {
                 if (gate.inFlight === request)
                     gate.inFlight = undefined;
-                if (chatGate.inFlight === request)
-                    chatGate.inFlight = undefined;
+                chatGate.pendingRequests--;
             });
             gate.inFlight = request;
-            chatGate.inFlight = request;
+            chatGate.pendingRequests++;
             return request;
         }
         try {

package/node_modules/@llblab/pi-telegram/dist/lib/updates.d.ts

@@ -1487,7 +1487,7 @@ export interface TelegramUpdateAdmissionLifecycleAssemblyDeps<TUpdate extends Te
     runtimeBinding: TelegramUpdateAdmissionRuntimeBinding<TContext>;
     inputCustodyBus?: TelegramInputCustodyBusBindingRuntime<TContext>;
     acquireSourceReference?: (role: "leader" | "follower", binding: TelegramUpdateAdmissionLifecycleJournalBinding) => () => void;
-    worker: Omit<TelegramUpdateAdmissionWorkerRuntimeDeps<TUpdate, TContext>, "journal" | "getJournalBindingKey" | "getRecipientBindingKey" | "hasAuthority" | "prepareUpdateForExecution" | "recoverRejectedRecipientTarget">;
+    worker: Omit<TelegramUpdateAdmissionWorkerRuntimeDeps<TUpdate, TContext>, "journal" | "getJournalBindingKey" | "getRecipientBindingKey" | "hasAuthority" | "prepareUpdateForExecution">;
     leader: {
         resolveBinding: () => TelegramUpdateAdmissionLifecycleJournalBinding | undefined;
         hasAuthority: (ctx: TContext) => boolean;
@@ -1497,7 +1497,6 @@ export interface TelegramUpdateAdmissionLifecycleAssemblyDeps<TUpdate extends Te
         isRegistered: () => boolean;
         getGeneration: () => string | undefined;
         prepareUpdateForExecution: (update: TUpdate) => TUpdate;
-        recoverRejectedRecipientTarget?: NonNullable<TelegramUpdateAdmissionWorkerRuntimeDeps<TUpdate, TContext>["recoverRejectedRecipientTarget"]>;
         /** Session succession before worker creation, under the exact generation-fenced binding. */
         prepareBinding?: (binding: TelegramUpdateAdmissionLifecycleJournalBinding & {
             hasAuthority?: () => boolean;
@@ -1509,19 +1508,6 @@ export type TelegramUpdateAdmissionWorkerRuntimeDeps<TUpdate extends TelegramJou
     inputCustody?: TelegramCustodyExecutionJournal;
     defaultHandle: (update: TUpdate, ctx: TContext, execution?: TelegramUpdateExecutionFence) => Promise<void>;
     prepareUpdateForExecution?: (update: TUpdate) => TUpdate;
-    /**
-     * Recipient-only recovery for a journaled message whose own Thread changed (for example after its Thread was re-created):
-     * classifies a leader refusal of a reply to the original Thread and returns that Thread plus the owner's current one.
-     */
-    recoverRejectedRecipientTarget?: (error: unknown) => {
-        rejected: {
-            chatId: number;
-            threadId: number;
-        };
-        current: TelegramTarget & {
-            threadId: number;
-        };
-    } | undefined;
     registry?: TelegramUpdateHandlerRegistry;
 };
 /** Compose source-bound routing and late grouped settlement under one worker. */

package/node_modules/@llblab/pi-telegram/dist/lib/updates.js

@@ -6359,7 +6359,6 @@ export function createTelegramUpdateAdmissionWorkerRuntime(deps) {
             const typedUpdate = update;
             const prepared = deps.prepareUpdateForExecution?.(typedUpdate) ?? typedUpdate;
             // Journal/source evidence remains the original; only the warm released handler projection changes destination.
-            // Journal/source evidence remains the original; only the warm released handler projection changes destination.
             const projectTo = (destination) => ({ ...prepared,
                 ...(prepared.message ? { message: prepared.message.message_thread_id === destination.threadId ? { ...prepared.message }
                         : withoutTelegramTurnReplyAnchor({ ...prepared.message, message_thread_id: destination.threadId, reply_to_message: undefined }) } : {}),
@@ -6374,17 +6373,8 @@ export function createTelegramUpdateAdmissionWorkerRuntime(deps) {
                 if (await deps.settleTerminalExecutionFailure?.(error)) {
                     return { kind: "complete" };
                 }
-                // The leader refused a reply to a Thread this recipient no longer owns (re-created after the input was journaled).
-                // Re-run once against its current Thread; any other failure, or a second refusal, keeps the ordinary retry state.
-                const recovery = !target ? deps.recoverRejectedRecipientTarget?.(error) : undefined;
-                const message = prepared.message ?? prepared.edited_message;
-                if (recovery && message && message.message_thread_id === recovery.rejected.threadId &&
-                    message.chat?.id === recovery.rejected.chatId && recovery.current.chatId === recovery.rejected.chatId &&
-                    recovery.current.threadId !== recovery.rejected.threadId) {
-                    deps.recordRuntimeEvent?.("inbound-worker", error, { phase: "recipient-target-recovery", updateId: update.update_id,
-                        chatId: recovery.current.chatId, staleThreadId: recovery.rejected.threadId, threadId: recovery.current.threadId });
-                    return await executeUpdate(projectTo(recovery.current), ctx, signal);
-                }
+                // A refused reply proves only that send was not issued, not that the handler made no prior effects.
+                // Leave failure settlement to the worker's retry policy; never re-enter the handler to recover delivery here.
                 throw error;
             }
         },
@@ -6457,9 +6447,6 @@ export function createTelegramUpdateAdmissionLifecycleAssembly(deps) {
                 spendHistoricalInput: undefined,
                 onHeldSourcesPrepared: undefined,
                 prepareUpdateForExecution: deps.follower.prepareUpdateForExecution,
-                ...(deps.follower.recoverRejectedRecipientTarget
-                    ? { recoverRejectedRecipientTarget: deps.follower.recoverRejectedRecipientTarget }
-                    : {}),
             });
         },
         recordRuntimeEvent: deps.recordRuntimeEvent,

package/node_modules/@llblab/pi-telegram/dist/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@llblab/pi-telegram",
-  "version": "0.57.7",
+  "version": "0.58.1",
   "private": false,
   "publishConfig": {
     "access": "public"

package/node_modules/@llblab/pi-telegram/docs/architecture.md

@@ -42,7 +42,7 @@ Keep this boundary explicit:
 
 ### Instance, Session, And Context Cost
 
-Live Telegram routing belongs to the active authenticated Pi instance, while a durable Workspace Thread belongs to the exact profile/CWD/session identity. Ordinary Telegram prompts enter the session currently bound to that target. Local `/resume` replaces session-scoped runtime state and selects the destination session's binding; it never inherits the source Thread merely because the process is unchanged. Telegram exposes compaction and new-session replacement for the active session: `/new` first completes and removes its exact durable update, then dispatches an internal registered Pi command through `pi.sendUserMessage(..., { expandPromptTemplates: true })` so the handler runs with a real `ExtensionCommandContext` and calls the same `AgentSessionRuntime.newSession()` path as the terminal. Before invoking that path, the current transport owner CAS-publishes one expiring replacement intent inside the existing profile target snapshot. The intent discriminates `workspace-thread` from `classic-chat`. A same- or cross-process successor may consume either only for the exact profile, CWD, source session, target, and fresh lifetime: Threaded continuity re-keys the retained Workspace binding and preserves Thread, slot, and display identity, while Classic continuity preserves the exact chat target without creating a Workspace binding or entering topic lifecycle APIs. A confirmed callback is acknowledged and its dialog is deleted before session replacement begins. Once the successor has delivery authority, it atomically claims the intent by CAS-clearing it and then sends one separate terminal success result with bounded in-process transport retry. The old `withSession` path never publishes success, and an unclaimed intent never sends, preventing duplicate terminal notices across same-process startup and cleanup-ack ambiguity. Mismatch or expiry never authorizes binding takeover. Resume, fork, tree navigation, session switching, and full reload remain outside the stable Telegram API until Pi exposes safe public extension hooks for them.
+Live Telegram routing belongs to the active authenticated Pi instance, while a durable Workspace Thread belongs to the exact profile/CWD/session identity. Ordinary Telegram prompts enter the session currently bound to that target. Local `/resume` replaces session-scoped runtime state and selects the destination session's binding; it never inherits the source Thread merely because the process is unchanged. Telegram exposes compaction and new-session replacement for the active session: `/new` first completes and removes its exact durable update, then dispatches the runtime-armed `/telegram-connect --internal new <token>` branch through `pi.sendUserMessage(..., { expandPromptTemplates: true })`, without entering ordinary Connect profile or transport startup, so the handler runs with a real `ExtensionCommandContext` and calls the same `AgentSessionRuntime.newSession()` path as the terminal. Before invoking that path, the current transport owner CAS-publishes one expiring replacement intent inside the existing profile target snapshot. The intent discriminates `workspace-thread` from `classic-chat`. A same- or cross-process successor may consume either only for the exact profile, CWD, source session, target, and fresh lifetime: Threaded continuity re-keys the retained Workspace binding and preserves Thread, slot, and display identity, while Classic continuity preserves the exact chat target without creating a Workspace binding or entering topic lifecycle APIs. A confirmed callback is acknowledged and its dialog is deleted before session replacement begins. Once the successor has delivery authority, it atomically claims the intent by CAS-clearing it and then sends one separate terminal success result with bounded in-process transport retry. The old `withSession` path never publishes success, and an unclaimed intent never sends, preventing duplicate terminal notices across same-process startup and cleanup-ack ambiguity. Mismatch or expiry never authorizes binding takeover. Resume, fork, tree navigation, session switching, and full reload remain outside the stable Telegram API until Pi exposes safe public extension hooks for them.
 
 `/telegram-connect` never launches a hidden or headless Pi process. A long-lived background Pi process can own Telegram only when something else explicitly launched that process and it satisfies the normal lock/runtime rules. Pi `print` and `json` modes stay passive and exit rather than becoming hidden polling owners.
 
@@ -685,7 +685,7 @@ Native typing during compaction follows connected-instance activity rather than
 - Thread-targeted typing is sent only to the concrete thread. Aggregate `All` mirroring is intentionally omitted because duplicating every keepalive multiplies shared-chat flood pressure. Compaction completion, failure, or timeout stops only a loop actually started by the compaction observer; a pre-existing agent-owned loop remains active. Ownership is sticky across a repeated compaction start, whose shared-loop start reports `false` for the observer's own running loop. Authority loss and shutdown still stop the keyed loop.
 - Pi `ui_prompt_start` pauses typing while an extension-owned local prompt waits for the operator; `ui_prompt_end` emits the matching Activity boundary and resumes typing whenever agent or compaction work remains unsettled.
 
-At every connected instance `agent_start`, the lifecycle binding starts Telegram's native `…typing` indicator in that instance's assigned target, whether the run came from Telegram, the local TUI, or an autonomous continuation such as Grow Loop. Terminal `Active` remains Telegram-turn-specific; the native indicator answers the separate question of whether the instance is doing agent work. Streaming keepalives reuse a valid typing owner with the same session generation, transport and target rather than revoking its pending HTTP/IPC action. Fresh context wrappers may reuse that owner within a proven generation; without generation evidence, context identity must match. Explicit queue dispatch and Telegram prompt handoff still replace the owner. Queue dispatch carries the queued turn's exact target into typing before `agent_start`, rather than reducing it to a chat ID. In Threaded Mode, missing or invalid Thread targets are refused before starting a loop or invoking the API; mode changes also invalidate a captured Classic chat-only loop. A rejected start never replaces an existing valid Thread loop. The starter also requires the captured Pi context and session generation to remain current at start, queued send, tick and late failure boundaries, even if the transport epoch is unchanged; replacing a context object in place cannot revive old activity. Message activity hooks capture generation across awaited preview work, and agent-start bindings recheck it before post-await activity/typing, so an obsolete finally or continuation cannot acquire replacement ownership. The typing sender carries its captured loop/context/generation/transport assertion as process-local call authority: direct API issuance rechecks it after queued work, and the follower caller rechecks it after registration waits and immediately before socket issuance without putting callbacks in IPC data. Automatic typing uses one HTTP attempt with no transport-family fallback or delayed replay, including forwarded calls; a future keepalive is a fresh owner-checked attempt. An already issued HTTP/RPC cannot be retroactively unsent. Each loop refreshes its exact target every three seconds and keeps one action in flight. The leader API runtime coalesces identical chat/thread/action calls for two seconds, permits at most one concurrent chat action per chat, and shares a Telegram 429 `retry_after` fence across every Thread key in that chat; expired gates prune opportunistically and each gate family retains at most 256 active keys. Suppression never schedules a delayed retry. A failed typing action remains a structured diagnostic but cannot project `error` onto an otherwise healthy connected/leader/follower status. Assistant message start/update hooks still re-arm typing during Telegram-owned turns so transient provider/model errors do not leave a continuing run without activity feedback, and agent/session completion stops it.
+At every connected instance `agent_start`, the lifecycle binding starts Telegram's native `…typing` indicator in that instance's assigned target, whether the run came from Telegram, the local TUI, or an autonomous continuation such as Grow Loop. Terminal `Active` remains Telegram-turn-specific; the native indicator answers the separate question of whether the instance is doing agent work. Streaming keepalives reuse a valid typing owner with the same session generation, transport and target rather than revoking its pending HTTP/IPC action. Fresh context wrappers may reuse that owner within a proven generation; without generation evidence, context identity must match. Explicit queue dispatch and Telegram prompt handoff still replace the owner. Queue dispatch carries the queued turn's exact target into typing before `agent_start`, rather than reducing it to a chat ID. In Threaded Mode, missing or invalid Thread targets are refused before starting a loop or invoking the API; mode changes also invalidate a captured Classic chat-only loop. A rejected start never replaces an existing valid Thread loop. The starter also requires the captured Pi context and session generation to remain current at start, queued send, tick and late failure boundaries, even if the transport epoch is unchanged; replacing a context object in place cannot revive old activity. Message activity hooks capture generation across awaited preview work, and agent-start bindings recheck it before post-await activity/typing, so an obsolete finally or continuation cannot acquire replacement ownership. The typing sender carries its captured loop/context/generation/transport assertion as process-local call authority: direct API issuance rechecks it after queued work, and the follower caller rechecks it after registration waits and immediately before socket issuance without putting callbacks in IPC data. Automatic typing uses one HTTP attempt with no transport-family fallback or delayed replay, including forwarded calls; a future keepalive is a fresh owner-checked attempt. An already issued HTTP/RPC cannot be retroactively unsent. Each loop refreshes its exact target every three seconds and keeps one action in flight. The leader API runtime coalesces identical chat/thread/action calls for two seconds, admits different Threads independently, and shares a real Telegram 429 `retry_after` fence across every Thread key in that chat. A pending-request count retains that shared state until every concurrent action settles, so completion of a faster peer cannot orphan a late 429; expired gates prune opportunistically and each gate family retains at most 256 active keys. Suppression never schedules a delayed retry. A failed typing action remains a structured diagnostic but cannot project `error` onto an otherwise healthy connected/leader/follower status. Assistant message start/update hooks still re-arm typing during Telegram-owned turns so transient provider/model errors do not leave a continuing run without activity feedback, and agent/session completion stops it.
 
 ### Rendering And Delivery
 

package/node_modules/@llblab/pi-telegram/docs/multi-instance-bus.md

@@ -485,7 +485,7 @@ Threaded Mode should make follower threads behave like normal Telegram instance
 | Replies/finals                   | Final replies land in the same thread                                                                                                                                                                                                                 | Follower finals go through leader transport into follower thread                                                                                                                                                                                                | Outbound calls carry target and inject `message_thread_id`                                                                                                                                                                                          | Reply delivery and bus API tests                                                                                          |
 | Previews/Rich Drafts             | Draft previews use the active thread target                                                                                                                                                                                                           | Follower previews use the same native draft lifecycle through the leader                                                                                                                                                                                        | Preview transport preserves target and draft id                                                                                                                                                                                                     | Preview thread-target tests                                                                                               |
 | Attachments/voice                | Files and voice upload in the instance thread                                                                                                                                                                                                         | Follower uploads route through leader multipart transport                                                                                                                                                                                                       | Multipart calls are target-scoped and follower-authorized                                                                                                                                                                                           | Bus allowlist and outbound delivery tests                                                                                 |
-| Native activity status           | `sendChatAction(typing)` refreshes Telegram's native `…typing` indicator only in the assigned Thread for every agent run, including local and autonomous work; aggregate `All` is not mirrored, terminal identity remains `connected`, and active work stays included in the green Queue count | Followers route the exact Thread action through leader transport while retaining their stable terminal `follower` identity and green activity count; the leader admits one concurrent action per chat and shares Telegram 429 cooldown across that chat's Thread keys                                                                                       | Agent lifecycle targets the active Telegram turn when present and otherwise the instance binding; one keyed loop avoids duplicate aggregate sends/rate-limit pressure                                                                               | Agent-start binding, typing-loop, target-routing, and terminal-status regressions                                         |
+| Native activity status           | `sendChatAction(typing)` refreshes Telegram's native `…typing` indicator only in the assigned Thread for every agent run, including local and autonomous work; aggregate `All` is not mirrored, terminal identity remains `connected`, and active work stays included in the green Queue count | Followers route the exact Thread action through leader transport while retaining their stable terminal `follower` identity and green activity count; the leader admits different Threads independently, coalesces exact chat/Thread/action calls and shares real Telegram 429 cooldown across that chat's Thread keys                                                                                       | Agent lifecycle targets the active Telegram turn when present and otherwise the instance binding; one keyed loop avoids duplicate aggregate sends/rate-limit pressure                                                                               | Agent-start binding, typing-loop, target-routing, and terminal-status regressions                                         |
 | Leader election / promotion      | Current leader keeps its thread across reload                                                                                                                                                                                                         | A promoted follower keeps its existing thread, slot, and name when elected and after later reload                                                                                                                                                               | Promotion converts the current follower binding into the leader profile before forced lock acquisition, so leader startup reuses it instead of provisioning a new thread                                                                            | Follower heartbeat recovery passes binding snapshot into promotion; own-topic provisioner reuses promoted bindings        |
 | `/start` command/menu bootstrap  | Registers visible bot commands and opens the menu                                                                                                                                                                                                     | Follower `/start` can refresh the bot command menu through the leader and open its local menu without warnings                                                                                                                                                  | Bot command registration is a validated global Bot API call allowed through trusted follower bus transport                                                                                                                                          | Bus allowlist regression for `setMyCommands`                                                                              |
 | Follower reconnect               | Existing leader binding is reused only when still usable                                                                                                                                                                                              | Same-process `/new` or `/reload` suspends the old follower socket/context and automatically re-registers the new session to the exact prior target; explicit reconnect to a genuinely closed/stale Telegram tab still recreates a visible thread before success | A short-lived handoff carries the assigned target across session replacement, and the leader transfers that binding to the new runtime instance id by stable manual-follower identity; stale Bot API errors remain the proof for fresh provisioning | Session handoff/refresh, leader binding-transfer, persisted leader-reload reuse, and stale-target replacement regressions |
@@ -673,12 +673,26 @@ This inspection authorizes no reload/restart, live-state mutation, fault injecti
 ## Security Boundaries
 
 - Messages, edits, callbacks, and reactions check user authorization, not only chat/thread membership.
-- Followers authenticate to the local leader IPC with a leader-minted capability secret carried in the active lock entry; registration, heartbeat, forwarded updates, and follower API calls without the secret are rejected. Registration rejections are surfaced verbatim in the follower `/telegram-connect` result, registration waits through leader-side Telegram thread provisioning, and successful registrations send an immediate heartbeat before the interval ticker so the leader does not prune a live follower before its first scheduled heartbeat. The local bus socket is also created under a private `0700` directory with `0600` socket permissions as a first local-only boundary. A reply refused because it targets a Thread other than the follower's own surfaces as the typed `TelegramApiFollowerNotAllowedError` carrying only the requested target. A journaled recipient input whose Thread was since re-created re-runs exactly once against the follower's current Thread (reply anchor cleared, diagnostic `recipient-target-recovery`); a second refusal or any other failure keeps the ordinary durable `retry-wait`.
+- Followers authenticate to the local leader IPC with a leader-minted capability secret carried in the active lock entry; registration, heartbeat, forwarded updates, and follower API calls without the secret are rejected. Registration rejections are surfaced verbatim in the follower `/telegram-connect` result, registration waits through leader-side Telegram thread provisioning, and successful registrations send an immediate heartbeat before the interval ticker so the leader does not prune a live follower before its first scheduled heartbeat. The local bus socket is also created under a private `0700` directory with `0600` socket permissions as a first local-only boundary. Follower API authorization refusal surfaces as `TelegramApiFollowerNotAllowedError` with the requested target when available. Only the leader's structured `follower-api-not-allowed` negative acknowledgement, emitted before API delegation and matched to the requested method, populates `rejectedRequestMethod`. Legacy error text, identical text thrown after delegation, a mismatched method or a lost acknowledgement supplies no such proof; old peers continue to receive the same human-readable rejection. The structured refusal proves only that the rejected API request was not executed, not that the command had no earlier effects. Admission therefore never immediately re-enters the handler or retargets its source to recover a reply. The original input remains in durable `retry-wait`; ordinary retries retain their documented at-least-once semantics. Safe reply-request recovery for re-created recipient Threads remains open in the backlog.
 - Follower Bot API proxying is allowlisted and target-scoped where applicable. Ordinary sends remain confined to the follower's assigned thread; trusted runtime-marked `telegram_message` cross-target sends may address only a different thread inside the same paired chat, and the leader strips the internal marker before calling Telegram. This preserves requested inter-thread delivery without granting arbitrary bot or cross-chat control.
 - Button and section callbacks verify authorized `from.id` and owning target/instance.
 - Generated artifacts stay scoped to the owning thread after leader failover.
 - Diagnostics redact bot tokens, large prompts, attachment paths, and handler output.
 
+### Reply Recovery Ownership Boundary
+
+A destination belongs to the complete delivery operation, not just the outgoing Bot API body. `replies.sendTelegramChunkSequence` captures one target for all chunks and records message ownership against it. Menu state independently retains `chatId`, `threadId` and the returned message ID through `menu-model.createTelegramMenuDelivery`. Its numeric send result cannot report a relocated Thread to the menu owner. Rewriting only a refused send's `message_thread_id` would therefore separate actual delivery from ownership and callback state; moving only later chunks would also split one reply across tabs.
+
+Follower API arguments use one private JSON-wire snapshot made before registration waits. Issued method/body, refusal target/method and slow-call diagnostics derive from that same snapshot; later caller mutations cannot relabel the attempt. Caller serialization runs once, with local authority checked before capture and again before issuance.
+
+Admission and recipient identity are separate. The local update execution fence carries its admission generation, update ID and abort signal; the queue-owner snapshot carries instance, process/birth and session-generation identity. Neither contains a complete recipient/session/profile/registration/target grant. Receipt and Workspace-admission namespaces are not the follower's registered profile key: selected-menu composition supplies that registered key separately, while the leader independently captures its active Workspace scope. No ordinary recipient-scoped reply-delivery lease joins these views today.
+
+Pre-publication destination selection is separate from refused-send recovery. For an executing private-DM follower journal, the status/model/settings and text-reply target adapters select the acknowledged recipient target while the active profile/session journal binding still matches the worker. The execution fence checks admission currency; it does not grant delivery. The selected target is passed to the menu owner before state construction and to the existing reply sender before chunking, with the old reply anchor removed on a Thread change. The original input and its journal are not rewritten. A different chat, a Thread-to-All fallback or missing recipient binding refuses selection; explicit selected-menu authority keeps its original fixed destination. The ordinary leader-side API authorization remains unchanged. This prevents a stale source address from choosing the initial reply destination; it neither relocates an issued request nor supplies the missing reply-recovery lease.
+
+Structured refusal is evidence about one API attempt, not a delivery or command recovery grant. Current delivery propagates that refusal without a replacement send, without editing the target or reply anchor, and without replaying acknowledged chunks. Already acknowledged messages keep their original ownership; the refused message acquires none. This applies to interactive HTML menus, split native Markdown and single Rich Message sections.
+
+Guarded follower delivery must use a recipient-scoped transport that enforces authority at the leader, not serialize a local callback through the ordinary proxy. The existing selected-menu channel is bound to an exact live-rebind operation, source cohort and recipient; a raw journaled command with no matching retained operation cannot borrow that grant. Any future reply-only recovery must establish its own exact authority, keep the destination consistent in delivery and menu ownership, clear stale reply metadata, and refuse relocation after partial publication or an unknown outcome. Handler-replay containment stays enabled until that boundary is proven; this is not an automatic recovery feature.
+
 ## Acceptance Criteria
 
 - [x] The lock semantics are redesigned as Telegram bus leadership with liveness proof and stale takeover rules.

package/node_modules/@llblab/pi-telegram/docs/public-api.md

@@ -44,6 +44,8 @@ Stable commands inside Pi:
 - `/telegram-disconnect` — after destructive confirmation, stop polling and release ownership without deleting or silencing accepted local queue state. A successful command queues the corresponding hidden, non-triggering disconnected context note; cancelled or failed disconnects do not publish a false state transition. In Threaded Mode it deletes this instance's current Telegram thread; a follower waits for its active leader to confirm generation-fenced cleanup before stopping. Graceful Pi `quit` performs the same teardown without prompting, while session replacement suspends transport without disconnect teardown. Local `/resume` carries connection intent rather than the source Thread; other supported replacements retain their existing continuity rules.
 - `/telegram-status` — show connection, polling, execution, queue, and recent event diagnostics; debug output separates poller and worker progress, durable automatic-retry state, exact foreign queued-owner identity, and negotiated protocol/build/capabilities.
 
+The `/telegram-connect --internal new <token>` form is a runtime-only dispatch, not a profile connection or a manual new-session shortcut. It requires the exact prepared one-use action and bypasses profile activation, connection intents and startup/recovery. Missing, forged, replayed, unsupported or malformed internal calls fail closed; invalid calls do not consume a valid pending action. The flag is reserved, but `internal` without the leading dashes remains a valid profile name. The standalone `/telegram-internal` command is no longer registered.
+
 ### Telegram commands
 
 - `/name Name` — set the durable manual display name of the current Thread. The routed leader or follower uses the authenticated target-fenced mutation and edits the visible title over the active automatic projection. Bare `/name` immediately opens expiring exact-target input; the next valid name is consumed before agent dispatch. Cancel is always available; **Reset to automatic** appears only when a manual name exists. Entering a bare uppercase slot letter such as `A` is also treated as an explicit reset to the current automatic display projection rather than as a manual name.
@@ -51,7 +53,7 @@ Stable commands inside Pi:
 Stable commands inside the paired Telegram DM:
 
 - `/start` — pair when needed and open the main application menu.
-- `/new` — after idle and empty-queue checks, request a new Pi session in the current classic chat or Thread. The bridge acknowledges the callback, deletes its confirmation, completes and removes the exact durable update, then dispatches one runtime-armed typed action through the internal `/telegram-internal` Pi gateway using `pi.sendUserMessage(..., { expandPromptTemplates: true })`. Manual invocation reports that the gateway cannot be run manually; the armed handler receives a real `ExtensionCommandContext` and calls `ctx.newSession()`; one discriminated durable intent preserves either exact classic Profile/CWD/session/chat continuity or the Thread binding with slot/name re-key. The successor CAS-claims that intent before sending one terminal result. In a follower Thread the leader publishes and claims the intent on the follower's behalf over capability-gated, exact-generation local bus requests; followers never persist leader-owned state. Busy, identity-mismatch, stale-registration, incompatible-leader, and unavailable-host paths fail closed.
+- `/new` — after idle and empty-queue checks, request a new Pi session in the current classic chat or Thread. The bridge acknowledges the callback, deletes its confirmation, completes and removes the exact durable update, then dispatches one runtime-armed typed action through the internal `/telegram-connect --internal new <token>` Pi gateway using `pi.sendUserMessage(..., { expandPromptTemplates: true })`. Manual invocation reports that the gateway cannot be run manually; the armed handler receives a real `ExtensionCommandContext` and calls `ctx.newSession()`; one discriminated durable intent preserves either exact classic Profile/CWD/session/chat continuity or the Thread binding with slot/name re-key. The successor CAS-claims that intent before sending one terminal result. In a follower Thread the leader publishes and claims the intent on the follower's behalf over capability-gated, exact-generation local bus requests; followers never persist leader-owned state. Busy, identity-mismatch, stale-registration, incompatible-leader, and unavailable-host paths fail closed.
 - `/compact` — open confirmation and compact when idle.
 - `/next` — abort active work first when needed, attempt the interrupted prompt's abort notice, then reply `Dispatching next queued turn.` to the exact queued prompt selected for the next model turn. That dispatch notice owns the turn's one reply header; later answer messages do not reply to the same prompt again. Abort-notice failure is diagnostic and cannot block dispatch. A later `/abort` or `/stop` cancels both pending transition notices before taking ownership. The `/next` command itself is never the lifecycle-notice reply target, and aborted pending assistant text is suppressed.
 - `/continue` — enqueue a priority `continue` prompt.

package/node_modules/@llblab/pi-telegram/lib/bindings.ts

@@ -869,6 +869,8 @@ export function createTelegramLiveTargetWorkObserver<TContext>(deps: {
 
 interface TelegramCommandsAndToolsBindingDeps {
   pi: Pi.ExtensionAPI;
+  handleInternalAction:
+    Commands.TelegramSessionActionRuntime["handleInternalAction"];
   agentDir: string;
   configStore: Config.TelegramConfigStore;
   persistConfig: (config?: Config.TelegramConfig) => Promise<void>;
@@ -926,6 +928,7 @@ interface TelegramCommandsAndToolsBindingDeps {
 
 export function registerTelegramCommandsAndTools({
   pi,
+  handleInternalAction,
   agentDir,
   configStore,
   persistConfig,
@@ -1023,6 +1026,7 @@ export function registerTelegramCommandsAndTools({
     );
   };
   Commands.registerTelegramBridgeCommands(pi, {
+    handleInternalAction,
     promptForConfig: async (ctx, profileName) => {
       const nextProfileName = profileName ?? undefined;
       if (profileName && !Config.isValidTelegramProfileName(profileName)) {

package/node_modules/@llblab/pi-telegram/lib/bus-follower.ts

@@ -1919,11 +1919,16 @@ export function createTelegramBusFollowerApiCaller(
     method: string,
     args: unknown[],
     localOptions: Pick<TelegramApiCallOptions, "assertAuthority"> | undefined,
-    timing: { registeredAtMs?: number },
+    timing: { registeredAtMs?: number; apiMethod?: string },
   ): Promise<unknown> => {
     const assertion = localOptions?.assertAuthority;
     const assertCurrent = () => assertTelegramApiCallAuthority(assertion, false);
     assertCurrent();
+    // Match IPC's JSON semantics once, before awaits; send and refusal metadata share this identity.
+    const requestArgs = JSON.parse(JSON.stringify(args)) as unknown[];
+    const apiMethod = (method === "call" || method === "callMultipart") && typeof requestArgs[0] === "string"
+      ? requestArgs[0] : method;
+    timing.apiMethod = apiMethod;
     const registration = await resolveTelegramBusFollowerRegistration(
       deps,
       timeoutMs,
@@ -1943,18 +1948,13 @@ export function createTelegramBusFollowerApiCaller(
           instanceId: deps.instanceId,
           registrationGeneration: registration.generation,
           method,
-          args,
+          args: requestArgs,
           sentAtMs: getNowMs(),
         },
         assertion ? assertCurrent : undefined,
       );
     } catch (error) {
       if (error instanceof TelegramBusLocalAuthorityError) throw new TelegramApiAuthorityError(error.requestIssued);
-      const apiMethod =
-        (method === "call" || method === "callMultipart") &&
-        typeof args[0] === "string"
-          ? args[0]
-          : method;
       if (!isTelegramApiMethodRetrySafe(apiMethod)) {
         throw new TelegramApiCommitUnknownError(apiMethod, error);
       }
@@ -1988,25 +1988,30 @@ export function createTelegramBusFollowerApiCaller(
         new Error(message ?? "Telegram bus API call result is ambiguous."),
       );
     }
-    if (message === TELEGRAM_BUS_FOLLOWER_API_NOT_ALLOWED_MESSAGE) {
+    const refusedMethod = response?.kind === "bus.ack" && !response.ok &&
+      response.error?.code === "follower-api-not-allowed" &&
+      response.error.method === apiMethod
+      ? apiMethod : undefined;
+    if (refusedMethod || message === TELEGRAM_BUS_FOLLOWER_API_NOT_ALLOWED_MESSAGE) {
       const body =
-        (method === "call" || method === "callMultipart") && isRecord(args[1])
-          ? args[1]
+        (method === "call" || method === "callMultipart") && isRecord(requestArgs[1])
+          ? requestArgs[1]
           : undefined;
       const chatId = Number(body?.chat_id);
       const threadId = Number(body?.message_thread_id);
       throw new TelegramApiFollowerNotAllowedError(
-        message,
+        message ?? TELEGRAM_BUS_FOLLOWER_API_NOT_ALLOWED_MESSAGE,
         Number.isSafeInteger(chatId) && Number.isSafeInteger(threadId)
           ? { chatId, threadId }
           : undefined,
+        refusedMethod,
       );
     }
     throw new Error(message ?? "Telegram bus API call failed.");
   };
   return async (method, args, localOptions) => {
     const startedAtMs = getNowMs();
-    const timing: { registeredAtMs?: number } = {};
+    const timing: { registeredAtMs?: number; apiMethod?: string } = {};
     let outcome = "ok";
     try {
       return await caller(method, args, localOptions, timing);
@@ -2016,11 +2021,7 @@ export function createTelegramBusFollowerApiCaller(
     } finally {
       const elapsedMs = getNowMs() - startedAtMs;
       if (elapsedMs >= slowCallMs) {
-        const apiMethod =
-          (method === "call" || method === "callMultipart") &&
-          typeof args[0] === "string"
-            ? args[0]
-            : method;
+        const apiMethod = timing.apiMethod ?? method;
         try {
           deps.recordRuntimeEvent?.(
             "bus",

package/node_modules/@llblab/pi-telegram/lib/bus-leader.ts

@@ -4189,10 +4189,17 @@ async function handleFollowerApiCall(
       args: envelope.args,
     })
   ) {
-    return rejectTelegramBusRequest(
-      envelope.requestId,
-      TELEGRAM_BUS_FOLLOWER_API_NOT_ALLOWED_MESSAGE,
-    );
+    const apiMethod = getFollowerApiMethodAndBody(envelope).apiMethod;
+    return {
+      ...rejectTelegramBusRequest(
+        envelope.requestId,
+        TELEGRAM_BUS_FOLLOWER_API_NOT_ALLOWED_MESSAGE,
+      ),
+      // Only this pre-dispatch authorizer refusal certifies that the API method was not called.
+      ...(/^[A-Za-z][A-Za-z0-9]{0,63}$/.test(apiMethod)
+        ? { error: { code: "follower-api-not-allowed" as const, method: apiMethod } }
+        : {}),
+    };
   }
   if (!deps.callApi) {
     return rejectTelegramBusRequest(

package/node_modules/@llblab/pi-telegram/lib/bus.ts

@@ -1260,6 +1260,7 @@ export type TelegramBusEnvelope = (
           | "ledger-overloaded"
           | "incompatible-protocol"
           | "stale-target"
+          | "follower-api-not-allowed"
           | "workspace-binding-unavailable";
         method?: string;
         chatId?: number;
@@ -4148,10 +4149,17 @@ function parseAckEnvelope(
       code === "ledger-overloaded" ||
       code === "incompatible-protocol" ||
       code === "stale-target" ||
+      code === "follower-api-not-allowed" ||
       code === "workspace-binding-unavailable"
     ) {
       const chatId = value.error.chatId;
       const threadId = value.error.threadId;
+      if (
+        code === "follower-api-not-allowed" &&
+        (value.ok || Object.hasOwn(value, "result") ||
+          typeof value.error.method !== "string" ||
+          !/^[A-Za-z][A-Za-z0-9]{0,63}$/.test(value.error.method))
+      ) return undefined;
       if (
         code === "stale-target" &&
         (!Number.isSafeInteger(chatId) || !Number.isSafeInteger(threadId))