polygram 0.10.0-rc.24 → 0.10.0-rc.26

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
   "name": "polygram",
-  "version": "0.10.0-rc.24",
+  "version": "0.10.0-rc.26",
   "description": "Telegram integration for Claude Code that preserves the OpenClaw per-chat session model. Migration target for OpenClaw users. Multi-bot, multi-chat, per-topic isolation; SQLite transcripts; inline-keyboard approvals. Bundles /polygram:status|logs|pair-code|approvals admin commands plus history (transcript queries) and polygram-send (out-of-turn IPC sends with file-upload validation) skills.",
   "keywords": [
     "telegram",

package/config.example.json

@@ -98,7 +98,8 @@
       "cwd": "/Users/you/admin-agent",
       "requireMention": true,
       "isolateTopics": true,
-      "_comment_topics": "rc.48: each topic entry is EITHER a string (legacy: just a label) OR an object with optional fields {name, agent, cwd, model, effort, permissionMode}. Object form lets a topic override chat-level config. Per-topic permissionMode overrides chat-level — typical use: scope one topic to permissionMode:'default' (so settings.json gates apply) while the rest of the chat stays on bypassPermissions. Object form requires isolateTopics: true (each topic gets its own SDK Query); polygram emits a startup warning otherwise.",
+      "_comment_topics": "rc.48: each topic entry is EITHER a string (legacy: just a label) OR an object with optional fields {name, agent, cwd, model, effort, permissionMode, isolateUserConfig}. Object form lets a topic override chat-level config. Per-topic permissionMode overrides chat-level — typical use: scope one topic to permissionMode:'default' (so settings.json gates apply) while the rest of the chat stays on bypassPermissions. Object form requires isolateTopics: true (each topic gets its own SDK Query); polygram emits a startup warning otherwise.",
+      "_comment_isolateUserConfig": "0.10.0, tmux backend only: isolateUserConfig:true spawns the topic's claude TUI cut off from the user-level ~/.claude config — passes --strict-mcp-config (zero MCP servers load) and --setting-sources project,local (drops ~/.claude/settings.json; the spawn cwd's own .claude/settings.json still loads). Use it when a topic's agent would otherwise inherit slow user-global MCP servers whose cold-start (tens of seconds) wedges the TUI before it can accept a prompt. Settable at chat OR topic level (topic wins). Default false.",
       "topics": {
         "100": "Customer A",
         "200": {
@@ -107,7 +108,8 @@
           "cwd": "/Users/you/customer-b-projects",
           "model": "opus",
           "effort": "high",
-          "permissionMode": "default"
+          "permissionMode": "default",
+          "isolateUserConfig": true
         }
       }
     },

package/lib/process/tmux-process.js

@@ -210,6 +210,12 @@ class TmuxProcess extends Process {
     queueCap = 50,   // P0.1 parity: SDK enforces queueCap=50 too
     pollScheduler = null,   // O1 optimization: shared cross-process tick
     pasteConfirmMs = 2500,  // Phase 3 §5: paste-gating JSONL-confirm timeout
+    // B7: a primary paste's submit is confirmed by its correlation
+    // token surfacing in a JSONL `user-message`. submitConfirmMs is the
+    // per-attempt wait for that line; submitConfirmRetries extra Enter
+    // presses before giving up loud.
+    submitConfirmMs = 1500,
+    submitConfirmRetries = 4,
   } = {}) {
     super({ sessionKey, chatId, threadId, label });
     if (!runner) throw new TypeError('TmuxProcess: runner required');
@@ -309,6 +315,24 @@ class TmuxProcess extends Process {
     this._pasteLock = createAsyncLock();
     this._pasteConfirms = new Map();   // token → resolve fn
     this.pasteConfirmMs = pasteConfirmMs;
+
+    // ─── B7: JSONL-token submit confirmation ──────────────────────
+    // shumorobot msgs 789 / 791 / 803: a large primary prompt collapses
+    // in the claude TUI into a `[Pasted text #N]` placeholder; the
+    // single post-paste Enter is absorbed mid-ingest and the prompt
+    // sits UNSUBMITTED — the turn never starts. B5 tried to confirm the
+    // submit by capture-pane, but the TUI renders the collapsed paste
+    // asynchronously, so capture-pane false-positives ("box looks
+    // clear → submitted ✓") on a transient frame. The ONLY reliable
+    // "the prompt reached claude" signal is the JSONL `user-message`
+    // line that reproduces THIS paste's correlation token verbatim.
+    // `_submitConfirms` maps token → resolve fn, fired ONLY by a
+    // `user-message` (NOT by `queue-operation enqueue` — an enqueue
+    // means the paste was parked in the TUI queue, not registered as a
+    // turn).
+    this._submitConfirms = new Map();   // token → resolve fn
+    this.submitConfirmMs = submitConfirmMs;
+    this.submitConfirmRetries = submitConfirmRetries;
   }
 
   get cost() { return 3; }
@@ -323,7 +347,7 @@ class TmuxProcess extends Process {
    *
    * @param {object} ctx
    * @param {string|null} [ctx.existingSessionId] — for --resume
-   * @param {object} [ctx.chatConfig={}]          — supplies model, effort, cwd, agent, permissionMode
+   * @param {object} [ctx.chatConfig={}]          — supplies model, effort, cwd, agent, permissionMode, isolateUserConfig
    * @param {string} [ctx.model]                  — override (rare; e.g. tests)
    * @param {string} [ctx.effort]                 — override
    * @param {string} [ctx.cwd]                    — override
@@ -354,6 +378,21 @@ class TmuxProcess extends Process {
       const cwd = ctx.cwd || topicConfig.cwd || chatConfig.cwd;
       const agent = topicConfig.agent || chatConfig.agent;
       const permissionMode = topicConfig.permissionMode || chatConfig.permissionMode || 'acceptEdits';
+      // `isolateUserConfig` (topic- or chat-level, topic wins — same
+      // merge path as agent/cwd/permissionMode). When true, the spawned
+      // claude TUI is cut off from the user-level `~/.claude` config:
+      // no user-level MCP servers, plugins, or settings load. Decided
+      // fix for the Music topic incident — the music-curation agent was
+      // pulling in user-global MCP servers (serena ~27.5 s, peekaboo
+      // ~9 s, context7) and the ~45 s MCP cold-start left the TUI
+      // accepting a pasted prompt but dropping the submitted Enter, so
+      // polygram's paste never submitted and the turn failed (broke the
+      // Music topic 5+ times). Default OFF — every other topic is
+      // unaffected unless it explicitly opts in.
+      const isolateUserConfig =
+        topicConfig.isolateUserConfig != null
+          ? topicConfig.isolateUserConfig === true
+          : chatConfig.isolateUserConfig === true;
 
       // Pre-allocate the sessionId via --session-id flag (v9 finding).
       // claude accepts a valid UUID and uses it as THE session ID for the
@@ -376,6 +415,25 @@ class TmuxProcess extends Process {
       }
       args.push('--debug-file', this.debugLogPath);
       if (agent) args.push('--agent', agent);
+      // isolateUserConfig: cut the spawned TUI off from `~/.claude`.
+      //   --strict-mcp-config    — claude CLI v2.1.142: "Only use MCP
+      //     servers from --mcp-config, ignoring all other MCP
+      //     configurations." Passed ALONE (no --mcp-config) → zero MCP
+      //     servers load. Hard guarantee that no plugin-provided OR
+      //     directly-registered MCP server (serena/peekaboo/context7)
+      //     starts, so there is no ~45 s cold-start window.
+      //   --setting-sources project,local — load only project + local
+      //     settings, NOT `user`. Drops `~/.claude/settings.json`
+      //     (user-level plugins/skills/settings) while the spawn cwd's
+      //     own `.claude/settings.json` still loads — so the rekordbox
+      //     project's WebFetch allowlist + dontAsk mode still apply.
+      // No --mcp-config needed: the music-curation plugin ships NO MCP
+      // server (its .claude-plugin/plugin.json declares no `mcpServers`;
+      // it is all-Bash), so --strict-mcp-config alone is clean.
+      if (isolateUserConfig) {
+        args.push('--strict-mcp-config');
+        args.push('--setting-sources', 'project,local');
+      }
       // Cross-backend parity: SDK appends polygram's Telegram display
       // hint to every agent's systemPrompt (lib/sdk/build-options.js).
       // Without this, the spawned claude session has no idea it's
@@ -563,15 +621,8 @@ class TmuxProcess extends Process {
       // rc.13.1: pasteAndEnter holds a per-session async lock around
       // paste + Enter so a concurrent injectUserMessage paste cannot
       // interleave keystrokes with this primary prompt.
-      //
-      // confirmSubmit: this is a PRIMARY turn pasting into an idle TUI
-      // (the previous turn finished before _runTurn drained this one).
-      // A production polygram prompt is ~1-2KB → the TUI collapses it
-      // into a bracketed-paste block whose single Enter can be
-      // absorbed (2026-05-18 incident). confirmSubmit re-sends Enter
-      // until the input box clears, or fails loud.
       const result = await this._pasteAndEnter(
-        this._embedToken(turn.prompt, turn.token), { confirmSubmit: true });
+        this._embedToken(turn.prompt, turn.token));
       if (result.stripped > 0) {
         this.logger.warn?.(
           `[${this.label}] stripped ${result.stripped} control chars from prompt`,
@@ -579,6 +630,34 @@ class TmuxProcess extends Process {
         this.emit('prompt-sanitized', { stripped: result.stripped, source: 'send' });
       }
 
+      // B7 (shumorobot msgs 789/791/803): a PRIMARY turn pasting into
+      // an idle TUI MUST start a turn. A production polygram prompt is
+      // ~1-2KB → the claude TUI collapses it into a `[Pasted text #N]`
+      // placeholder whose single post-paste Enter can be absorbed
+      // mid-ingest, leaving the prompt UNSUBMITTED — the turn never
+      // starts. `_confirmSubmitViaJsonl` confirms the submit landed by
+      // waiting for this paste's correlation token to surface in a
+      // JSONL `user-message` (the ONLY reliable signal — capture-pane
+      // false-positives on the collapsed placeholder); it re-sends
+      // Enter on a miss and, after bounded retries, REJECTS with
+      // TMUX_SUBMIT_FAILED.
+      //
+      // The confirm drives TWO derived promises below:
+      //   submitConfirmP — rejects TMUX_SUBMIT_FAILED → a racer that
+      //     fails the turn fast and loud; on success it never settles.
+      //   submitOkP      — resolves ONLY once the submit is confirmed;
+      //     on failure it never settles. It GATES the capture-pane
+      //     racer: an "idle" capture-pane is meaningless until the turn
+      //     has actually started — pre-gate, a `[Pasted text #N]`
+      //     prompt sitting unsubmitted reads as an idle (=="complete")
+      //     pane, so the capture racer would win with TMUX_NO_JSONL_TEXT
+      //     and mask the real TMUX_SUBMIT_FAILED cause.
+      const confirmP = turn.token
+        ? this._confirmSubmitViaJsonl(turn.token, turn)
+        : Promise.resolve();             // no token — nothing to confirm
+      const submitConfirmP = confirmP.then(() => new Promise(() => {}));
+      const submitOkP = confirmP.then(() => true, () => new Promise(() => {}));
+
       // R7: an ABSOLUTE timeout wrapping the whole race. The
       // capture-pane completion detector re-checks its deadline only
       // BETWEEN `captureWide` subprocess calls — if a single `tmux
@@ -617,11 +696,32 @@ class TmuxProcess extends Process {
         timeoutMs: turnTimeoutMs, abortP,
       });
       // The capture-pane loop may end via the absolute-deadline abort
-      // (it returns the abort sentinel). Swallow that branch — the
-      // turnDeadlineP reject below is what actually fails the turn.
-      const captureRaceP = captureCompleteP.then((buf) => (
-        buf === ABORT_SENTINEL ? new Promise(() => {}) : { kind: 'capture' }
-      ));
+      // (it returns the abort sentinel) or reject (its own timeout).
+      // Both are swallowed here — the `turnDeadlineP` reject below is
+      // what actually fails the turn.
+      //
+      // B7: gate the capture racer behind `submitOkP`. A capture-pane
+      // "idle" reading only means "the turn completed" once the turn
+      // has actually STARTED. If the paste never submitted, the pane is
+      // idle because the prompt is still sitting in the input box — not
+      // because a turn finished. Without the gate the capture racer
+      // would win with TMUX_NO_JSONL_TEXT and mask the real
+      // TMUX_SUBMIT_FAILED. `captureCompleteP` is still awaited inside
+      // the racer (so its rejection is always handled — never orphaned
+      // into an unhandled rejection) and the poll loop / scheduler
+      // refcount lifecycle is unchanged; only the racer's eligibility
+      // to WIN is gated on submit confirmation.
+      const captureRaceP = (async () => {
+        let buf;
+        try {
+          buf = await captureCompleteP;
+        } catch {
+          return new Promise(() => {});   // capture's own timeout — turnDeadlineP fails the turn
+        }
+        if (buf === ABORT_SENTINEL) return new Promise(() => {});
+        await submitOkP;                  // gate: capture cannot win pre-submit-confirm
+        return { kind: 'capture' };
+      })();
 
       let resolvedVia = 'jsonl';
       let winner;
@@ -631,6 +731,8 @@ class TmuxProcess extends Process {
           captureRaceP,
           turnDeadlineP,
           turn.interruptP.then(() => ({ kind: 'interrupt' })),
+          // B7: TMUX_SUBMIT_FAILED rejection fails the turn fast.
+          submitConfirmP,
         ]);
 
         // If capture-pane won but the turn used a tool, the agent is
@@ -1151,6 +1253,10 @@ class TmuxProcess extends Process {
     // Phase 3 §5: a user-message proves its pastes landed — release
     // the paste gate for those tokens.
     this._confirmPaste(tokens);
+    // B7: a user-message is the proof that a primary paste actually
+    // STARTED a turn (claude registered the prompt). Release any
+    // _confirmSubmitViaJsonl waiter for these tokens.
+    this._confirmSubmit(tokens);
     let matched = [];
     for (const tok of tokens) {
       const t = this._ledger.find(
@@ -1166,7 +1272,15 @@ class TmuxProcess extends Process {
         const orphan = this._ledger.find(
           (x) => x.kind === 'primary' && x.state === 'pasted',
         );
-        if (orphan) matched = [orphan];
+        if (orphan) {
+          matched = [orphan];
+          // B7: a token-less user-message claimed by the orphan
+          // fallback still PROVES that primary's prompt started — so
+          // release its submit-confirm waiter under the orphan's own
+          // token (the `_confirmSubmit(tokens)` above could not, the
+          // user-message carried no token to match).
+          this._confirmSubmit([orphan.token]);
+        }
       }
       if (matched.length === 0) {
         // Genuinely unrecognised — diagnostic, then ignore. (A
@@ -1290,19 +1404,33 @@ class TmuxProcess extends Process {
    * pastes can no longer concatenate. The lock is released
    * asynchronously (on confirm/timeout) so it gates only the NEXT
    * paste, never delays this caller.
+   *
+   * B7 (shumorobot msgs 789/791/803): `_pasteAndEnter` does NOT itself
+   * confirm the paste SUBMITTED. A large prompt collapses in the claude
+   * TUI into a `[Pasted text #N]` placeholder whose single post-paste
+   * Enter can be absorbed mid-ingest, leaving the prompt unsubmitted —
+   * but that submit-confirmation runs as a concurrent racer in
+   * `_runTurn` (`_confirmSubmitViaJsonl`), NOT here. Blocking
+   * `_pasteAndEnter` on the confirm would hold `_pasteLock` across the
+   * whole confirm window and stall every following paste — an autosteer
+   * that should fold into the primary turn could never paste.
    */
-  async _pasteAndEnter(text, { confirmSubmit = false } = {}) {
+  async _pasteAndEnter(text) {
     const token = this._extractTokens(text)[0] || null;
     const release = await this._pasteLock.acquire(this.tmuxName);
     let result;
     try {
+      // B7: the runner no longer does capture-pane submit-confirmation
+      // (it false-positived on `[Pasted text #N]`). The runner just
+      // pastes + Enter. Submit confirmation for a PRIMARY turn is
+      // JSONL-token-based and runs as a CONCURRENT racer in `_runTurn`
+      // (`_confirmSubmitViaJsonl`) — NOT here. Blocking `_pasteAndEnter`
+      // on the confirm would hold `_pasteLock` across the whole confirm
+      // window and stall every following paste (an autosteer that
+      // SHOULD fold into the primary turn could never paste). The
+      // confirm is a watchdog, not a paste-pipeline gate.
       if (typeof this.runner.pasteAndEnter === 'function') {
-        // 2026-05-18 incident: confirmSubmit re-sends Enter if a large
-        // bracketed paste didn't submit. ONLY for a primary turn's
-        // paste into an idle TUI — never for an autosteer paste into a
-        // mid-turn TUI (the TUI parks that in its own queue; the input
-        // box holding it is expected, not a failed submit).
-        result = await this.runner.pasteAndEnter(this.tmuxName, text, { confirmSubmit });
+        result = await this.runner.pasteAndEnter(this.tmuxName, text);
       } else {
         result = await this.runner.pasteText(this.tmuxName, text);
         await this.runner.sendControl(this.tmuxName, 'Enter');
@@ -1321,6 +1449,91 @@ class TmuxProcess extends Process {
     return result;
   }
 
+  /**
+   * B7: confirm a primary paste actually submitted by waiting for its
+   * correlation `token` to surface in a JSONL `user-message`. On each
+   * miss, re-send Enter (the prior Enter was absorbed by the TUI's
+   * bracketed-paste ingest of a `[Pasted text #N]` block). After
+   * `submitConfirmRetries` exhausted misses, throw `TMUX_SUBMIT_FAILED`.
+   *
+   * The signal is the `user-message` ONLY — not `queue-operation`. A
+   * `queue-operation enqueue` means the paste was parked in the TUI
+   * queue, which for a primary paste into an idle TUI would itself be
+   * wrong; the genuine "the prompt started a turn" proof is the
+   * `user-message` claude writes when it registers the prompt.
+   *
+   * Runs as a concurrent racer in `_runTurn` (NOT a blocking gate in
+   * `_pasteAndEnter` — that would hold `_pasteLock` across the confirm
+   * window and stall a folding autosteer's paste). `turn` is the owning
+   * Turn: if it reaches a terminal state (the real result/capture
+   * racer already won, or the turn was killed) the retry loop bails so
+   * a stray retry Enter cannot land in an unrelated turn.
+   */
+  async _confirmSubmitViaJsonl(token, turn = null) {
+    for (let attempt = 0; attempt <= this.submitConfirmRetries; attempt += 1) {
+      const confirmed = await this._awaitSubmitConfirm(token);
+      if (confirmed) return;                            // submitted ✓
+      // The turn already settled some other way (result/capture/kill)
+      // — the submit clearly is no longer the open question. Stop:
+      // re-sending Enter or throwing now would be wrong.
+      if (turn && (turn.state === 'done' || turn.state === 'failed')) return;
+      if (attempt === this.submitConfirmRetries) break; // out of retries
+      // The tokened user-message never arrived — the prompt is still
+      // sitting in the input box as `[Pasted text #N]`. Re-send Enter.
+      this.logger.debug?.(
+        `[${this.label}] paste not submitted (no user-message for ${token}), `
+        + `re-sending Enter (attempt ${attempt + 1})`,
+      );
+      try {
+        await this.runner.sendControl(this.tmuxName, 'Enter');
+      } catch (err) {
+        // A dead session — the turn will fail loud via another racer.
+        this.logger.debug?.(`[${this.label}] retry Enter failed: ${err.message}`);
+        return;
+      }
+    }
+    throw Object.assign(
+      new Error(
+        `TmuxProcess: prompt never submitted — no JSONL user-message for `
+        + `${token} after ${this.submitConfirmRetries + 1} Enter attempts`,
+      ),
+      { code: 'TMUX_SUBMIT_FAILED', tmuxName: this.tmuxName, token },
+    );
+  }
+
+  /**
+   * Resolve `true` once `token` surfaces in a JSONL `user-message`
+   * (via `_confirmSubmit`), or `false` after `submitConfirmMs`.
+   * Distinct from `_awaitPasteConfirm`: that releases the next-paste
+   * barrier on user-message OR queue-operation; this confirms a turn
+   * actually STARTED, so it accepts the `user-message` signal only.
+   */
+  _awaitSubmitConfirm(token) {
+    return new Promise((resolve) => {
+      let done = false;
+      let timer = null;
+      const finish = (ok) => {
+        if (done) return;
+        done = true;
+        if (timer) clearTimeout(timer);
+        this._submitConfirms.delete(token);
+        resolve(ok);
+      };
+      this._submitConfirms.set(token, () => finish(true));
+      timer = setTimeout(() => finish(false), this.submitConfirmMs);
+      timer.unref?.();
+    });
+  }
+
+  /** B7: mark tokens as submit-confirmed — fired from a JSONL
+   *  `user-message` (NOT queue-operation). */
+  _confirmSubmit(tokens) {
+    for (const t of tokens) {
+      const finish = this._submitConfirms.get(t);
+      if (finish) finish();
+    }
+  }
+
   /**
    * Resolve once `token` surfaces in a JSONL user-message /
    * queue-operation, or after `pasteConfirmMs` (bounded barrier).
@@ -1927,6 +2140,18 @@ class TmuxProcess extends Process {
     for (const finish of [...this._pasteConfirms.values()]) {
       try { finish(); } catch { /* swallow */ }
     }
+    // B7: release any pending submit-confirm waiters too — a
+    // `_confirmSubmitViaJsonl` blocked on a tokened user-message from a
+    // now-dead session would otherwise burn its whole retry budget.
+    // Each waiter's stored fn resolves it as confirmed, so the confirm
+    // loop returns at once instead of retrying; the in-flight turn is
+    // already rejected by `drainQueue` above, so the turn settles loud
+    // regardless. (`_confirmSubmitViaJsonl` also bails on its own when
+    // the owning turn reaches a terminal state — this is belt-and-
+    // braces for a confirm whose turn ref it never received.)
+    for (const finish of [...this._submitConfirms.values()]) {
+      try { finish(); } catch { /* swallow */ }
+    }
     if (this._sessionLogTail) {
       try { this._sessionLogTail.close(); } catch { /* swallow */ }
       this._sessionLogTail = null;

package/lib/tmux/tmux-runner.js

@@ -46,78 +46,65 @@ const MULTILINE_SEPARATOR = ' / ';
 // via MULTILINE_SEPARATOR.
 const CONTROL_CHAR_RE = /[\x00-\x08\x0b-\x1f\x7f]/g;
 
-// 2026-05-18 incident: a ~1.2KB polygram prompt is collapsed by the
-// claude TUI into a bracketed-paste block rendered as "[Pasted text
-// #1]". A single Enter sent after the fixed paste drain does NOT
-// submit it — the Enter is absorbed while the TUI is still ingesting
-// the block, so the prompt sits unsubmitted in the input box and the
-// turn never starts. `pasteAndEnter` confirms the submit landed by
-// capture-pane and re-sends Enter if it didn't.
-
-// The claude TUI draws its input box bracketed by horizontal-rule
-// lines (long runs of the box-drawing char `─`). The input prompt is
-// a `❯`-prefixed line BETWEEN those rules. CRUCIALLY, a SUBMITTED
-// message is ALSO echoed with a `❯` prefix up in the conversation
-// area — so a naive "any ❯ line with paste content" check
-// false-positives on the echo of a just-submitted prompt. The input
-// box must be identified structurally: it is the `❯` line adjacent
-// to a horizontal rule.
-const TUI_RULE_RE = /^[^\S\n]*─{20,}[^\S\n]*$/;
-
-// Markers that mean "this line is holding an un-submitted paste":
-// the bracketed-paste collapse marker, or a polygram-prompt opening
-// tag (polygram only ever sends those as a paste body).
-const HELD_PASTE_RE = /\[Pasted text|<polygram-info|<session-context|<channel\b/;
-
-/**
- * 2026-05-18 incident detector. Returns true when the claude TUI's
- * INPUT BOX still holds an un-submitted paste — i.e. the prompt was
- * pasted but the Enter did not submit it.
- *
- * Identifies the input box structurally: the `❯`-prefixed line that
- * is adjacent to a horizontal-rule line. That distinguishes the live
- * input box from the `❯`-prefixed echo of an already-submitted
- * message in the conversation area (which would otherwise
- * false-positive). An empty input box (`❯ ` with nothing after it)
- * returns false — that is a clean, submitted state.
- */
-function inputBoxHoldsPaste(pane) {
-  const lines = String(pane || '').split('\n');
-  for (let i = 0; i < lines.length; i += 1) {
-    const m = lines[i].match(/^[^\S\n]*❯[^\S\n]?(.*)$/);
-    if (!m) continue;
-    // Adjacent to a horizontal rule above or below ⇒ this is the
-    // input box, not a submitted-message echo.
-    const ruleAbove = i > 0 && TUI_RULE_RE.test(lines[i - 1]);
-    const ruleBelow = i + 1 < lines.length && TUI_RULE_RE.test(lines[i + 1]);
-    if (!ruleAbove && !ruleBelow) continue;
-    if (HELD_PASTE_RE.test(m[1])) return true;
-  }
-  return false;
-}
-
-// Submit-confirmation defaults — overridable per construction for
-// tests. `retries` extra Enter presses after the first; `pollMs` the
-// settle wait before each capture-pane check; `drainMs` the wait
-// after a re-sent Enter before re-checking.
-const DEFAULT_SUBMIT_CONFIRM = { retries: 4, pollMs: 200, drainMs: 250 };
+// 2026-05-18 incident — submit confirmation now lives in TmuxProcess.
+// A ~1-2KB polygram prompt is collapsed by the claude TUI into a
+// "[Pasted text #N]" placeholder; the single post-paste Enter can be
+// absorbed mid-ingest, leaving the prompt unsubmitted.
+//
+// B5 confirmed the submit HERE by capture-pane (does the input box
+// still hold the paste?). That FALSE-POSITIVED: the TUI renders the
+// collapsed-paste placeholder asynchronously, so a capture-pane poll
+// catches a transient frame where the placeholder is not yet visible
+// and B5 wrongly concluded "submitted ✓", leaving the prompt stuck
+// (3rd recurrence: shumorobot msg 803, 2026-05-19). B7 REMOVED the
+// capture-pane confirm — capture-pane is an unreliable signal for a
+// collapsed paste. Submission is now confirmed in `TmuxProcess` by the
+// paste's correlation token surfacing in a JSONL `user-message` (the
+// only reliable "the prompt reached claude" signal). The runner just
+// pastes + Enter; it no longer judges whether the submit landed.
 
 // ─── execFile wrapper ────────────────────────────────────────────────
 
+// Every tmux invocation polygram makes — capture-pane, send-keys,
+// set-buffer, paste-buffer, has-session, list-sessions, kill-session,
+// and even `new-session -d` (which detaches immediately) — is a
+// sub-second operation. A tmux call that runs longer than this is
+// WEDGED (tmux server hung, host pathologically loaded).
+//
+// Without a bound, a wedged subprocess hangs the `await` forever:
+// `_awaitTurnComplete`'s poll loop re-checks its deadline only
+// BETWEEN `captureWide` calls, so a single hung `capture-pane` stalls
+// the turn with no timeout (leftover R7). The 2026-05-18 submit-
+// confirm loop has the same exposure — it capture-panes too.
+//
+// A per-exec timeout bounds ALL of it: a timed-out tmux call rejects
+// → the caller throws → the turn fails LOUD with an error instead of
+// hanging. killSignal is SIGKILL because a wedged process may ignore
+// SIGTERM. 10s is generous headroom over the sub-second norm.
+const TMUX_RUN_TIMEOUT_MS = 10_000;
+
 /**
  * Promise-wrapped childProcess.execFile. Returns { stdout, stderr }.
- * Rejects on non-zero exit with err.stdout + err.stderr attached.
+ * Rejects on non-zero exit (or timeout) with err.stdout + err.stderr
+ * attached. A default timeout + SIGKILL bound every tmux call so a
+ * wedged subprocess cannot hang a turn (leftover R7); an explicit
+ * `opts.timeout` still overrides.
  */
 function run(cmd, args, opts = {}) {
   return new Promise((resolve, reject) => {
-    childProcess.execFile(cmd, args, { ...opts, encoding: 'utf8' }, (err, stdout, stderr) => {
-      if (err) {
-        err.stdout = stdout;
-        err.stderr = stderr;
-        return reject(err);
-      }
-      resolve({ stdout, stderr });
-    });
+    childProcess.execFile(
+      cmd,
+      args,
+      { timeout: TMUX_RUN_TIMEOUT_MS, killSignal: 'SIGKILL', ...opts, encoding: 'utf8' },
+      (err, stdout, stderr) => {
+        if (err) {
+          err.stdout = stdout;
+          err.stderr = stderr;
+          return reject(err);
+        }
+        resolve({ stdout, stderr });
+      },
+    );
   });
 }
 
@@ -195,16 +182,11 @@ function ensureLogDir(logPath) {
  * @param {object} [opts.logger=console]
  * @param {Function} [opts.runFn] — override the underlying execFile
  *   wrapper (for tests). Same signature: (cmd, args, opts?) → Promise.
- * @param {object} [opts.submitConfirm] — large-paste submit-confirm
- *   tunables { retries, pollMs, drainMs }; tests shorten these.
  */
 function createTmuxRunner({
   logger = console,
   runFn = run,
-  submitConfirm = {},
 } = {}) {
-  const submitCfg = { ...DEFAULT_SUBMIT_CONFIRM, ...submitConfirm };
-
   async function spawn({
     name,
     cwd,
@@ -278,21 +260,17 @@ function createTmuxRunner({
   /**
    * Paste a prompt body + press Enter, atomically per session.
    *
+   * Pure mechanics: paste, Enter, a small post-Enter drain. The runner
+   * does NOT judge whether the submit landed — B7 moved submit
+   * confirmation to `TmuxProcess`, which confirms it via the paste's
+   * correlation token surfacing in a JSONL `user-message` (the only
+   * reliable signal; capture-pane false-positives on a collapsed
+   * `[Pasted text #N]` placeholder).
+   *
    * @param {string} name  tmux session
    * @param {string} text  prompt body
-   * @param {object} [opts]
-   * @param {boolean} [opts.confirmSubmit=false] — when true, CONFIRM
-   *   the Enter actually submitted the prompt (capture-pane the input
-   *   box, re-send Enter if it still holds the paste, throw if it
-   *   never clears). Use ONLY for a primary turn's paste into an
-   *   IDLE TUI — the 2026-05-18 large-bracketed-paste bug. Must be
-   *   FALSE for an autosteer paste into a BUSY (mid-turn) TUI: there
-   *   the TUI legitimately parks the paste in its own input queue
-   *   (`queue-operation enqueue`), so the input box holding the paste
-   *   is EXPECTED, not a failed submit — re-sending Enter into a
-   *   streaming TUI would corrupt the queue.
    */
-  async function pasteAndEnter(name, text, { confirmSubmit = false } = {}) {
+  async function pasteAndEnter(name, text) {
     const release = await inputLock.acquire(name);
     try {
       const res = await pasteText(name, text);
@@ -306,46 +284,7 @@ function createTmuxRunner({
       // Enter's processing. 50ms is enough on the TUI we tested
       // against (claude v2.1.142); see AGENTS.md pinned version.
       await new Promise((r) => setTimeout(r, 50));
-
-      // 2026-05-18 incident: a large (~1.2KB) bracketed paste is NOT
-      // submitted by that single Enter — the Enter is absorbed while
-      // the TUI is still ingesting the "[Pasted text #1]" block. The
-      // fixed drain is a timing guess that fails for big pastes.
-      // CONFIRM the submit landed by capture-pane; if the input box
-      // still holds the paste, re-send Enter (bounded retries). If it
-      // never clears, throw — pasteAndEnter must not report success
-      // for an unsubmitted prompt (a fake THINKING state otherwise).
-      //
-      // ONLY for a primary paste into an idle TUI (confirmSubmit). An
-      // autosteer paste into a mid-turn TUI is DELIBERATELY parked in
-      // the TUI's input queue — the input box holding it is correct,
-      // not a failure; re-sending Enter there would corrupt the queue.
-      if (!confirmSubmit) return res;
-      for (let attempt = 0; attempt <= submitCfg.retries; attempt += 1) {
-        await new Promise((r) => setTimeout(r, submitCfg.pollMs));
-        let pane;
-        try {
-          pane = await capturePane(name, { lines: 60 });
-        } catch (err) {
-          // capture-pane itself failed — can't confirm. Don't claim
-          // success; surface it.
-          throw Object.assign(
-            new Error(`pasteAndEnter: submit confirmation failed: ${err.message}`),
-            { code: 'TMUX_SUBMIT_FAILED', cause: err },
-          );
-        }
-        if (!inputBoxHoldsPaste(pane)) return res;   // submitted ✓
-        if (attempt === submitCfg.retries) break;    // out of retries
-        // Still stuck — the paste sits in the input box. Re-send
-        // Enter and give the TUI a moment before re-checking.
-        logger.debug?.(`[tmux-runner] ${name}: paste not submitted, re-sending Enter (attempt ${attempt + 1})`);
-        await sendControl(name, 'Enter');
-        await new Promise((r) => setTimeout(r, submitCfg.drainMs));
-      }
-      throw Object.assign(
-        new Error(`pasteAndEnter: prompt never submitted after ${submitCfg.retries + 1} Enter attempts`),
-        { code: 'TMUX_SUBMIT_FAILED', tmuxName: name },
-      );
+      return res;
     } finally {
       release();
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "polygram",
-  "version": "0.10.0-rc.24",
+  "version": "0.10.0-rc.26",
   "description": "Telegram daemon for Claude Code that preserves the OpenClaw per-chat session model. Migration path for OpenClaw users moving to Claude Code.",
   "main": "lib/ipc/client.js",
   "bin": {