PAI/PULSE/modules/telegram.ts: short messages produce empty replies (numTurns=0); literal {{DA_NAME}}/{{PRINCIPAL_NAME}} reach SDK and chat-log

[jmmarkiewicz]

Summary

Two related runtime bugs in PAI/PULSE/modules/telegram.ts that bite together: short user replies ("Agreed", "OK", "thanks") return the fallback "Sorry, I wasn't able to generate a response. Try again?" instead of a real response. And the bot's runtime systemPrompt has literal {{DA_NAME}} / {{PRINCIPAL_NAME}} placeholder strings — the substitution gap #1135 calls out for PAI_SYSTEM_PROMPT.md is not applied to TypeScript source either.

---

Bug 1 — SDK session resume + manual history-prepend produces numTurns: 0 on short messages

telegram.ts:182-188 builds a prompt that prepends the last 10 messages of conversation history as plain text:

prompt = `Previous conversation:\n${historyText}\n\nPrincipal's new message: ${sanitized}`

telegram.ts:218-221 ALSO sets sdkOptions.resume = lastSessionId, resuming the prior agent session that already contains the same history:

if (lastSessionId) {
  sdkOptions.resume = lastSessionId
}

So the SDK gets the conversation history twice. For long content-rich messages it muddles through. For short acknowledgments after a complex multi-turn previous response, the resumed agent loop short-circuits with numTurns: 0, cost: 0 after ~3s — the agent sees the new "Agreed" as redundant against its existing transcript and never issues a model call. The SDK returns no streamed text, fullText stays empty at telegram.ts:293, and telegram.ts:294 substitutes the "Sorry, I wasn't able..." fallback string.

Receipts

Six consecutive turns from one session, all sharing the same sessionId:

User message	numTurns	cost ($)	Outcome
(37 chars, work)	1	0.27	OK
(38 chars)	1	0.28	OK
(130 chars)	13	0.86	OK
(998 chars)	1	0.40	OK
Agreed (6 chars)	0	0	fallback
I agreed to what you proposed (29 chars)	0	0	fallback

Pulse log lines for the failing turn:

"Message received" textLength=6
"Session initialized" sessionId=d0eb813d-...
"SDK session complete" durationMs=3088 numTurns=0 cost=0 sessionId=d0eb813d-...
"Empty response from SDK"
"Response sent" responseLength=55

Suggested fix

Pick one of the two history paths, not both:

• Option A — drop resume. Each turn starts fresh; the manually-prepended history is the only context. Simpler and avoids the SDK's "this session already produced an answer" short-circuit.
• Option B — keep resume, drop the manual prepend. Trust the SDK's session memory to carry context.

I'd lean toward Option A for predictability — the resumed-session code path also accumulates max-turns budget across resumes, which is a separate latent issue.

---

Bug 2 — Literal {{DA_NAME}} / {{PRINCIPAL_NAME}} strings reach the SDK and the chat log

telegram.ts:201-214 constructs the systemPrompt body with hardcoded placeholder strings that are never substituted at runtime:

append: `\n\n## TELEGRAM MODE OVERRIDE (highest priority — overrides CLAUDE.md format rules)

You are {{DA_NAME}}, responding via Telegram. {{PRINCIPAL_NAME}} is messaging you from his phone.

CRITICAL RULES FOR TELEGRAM MODE:
- ...
- Speak as {{DA_NAME}} — first person, natural, conversational, like talking to a friend
...

So the bot's runtime system prompt literally contains the strings {{DA_NAME}} and {{PRINCIPAL_NAME}}. Same issue in the chat-log writer at telegram.ts:71-79:

const entry = `\n### ${ts}\n**{{PRINCIPAL_NAME}}:** ${userMsg}\n\n**{{DA_NAME}}:** ${botMsg}\n\n---\n`

Result in ~/.claude/PAI/PULSE/logs/telegram/chat-log.md:

**{{PRINCIPAL_NAME}}:** Agreed
**{{DA_NAME}}:** Sorry, I wasn't able to generate a response. Try again?

Reproduce

grep -nE '\{\{[A-Z_]+\}\}' ~/.claude/PAI/PULSE/modules/telegram.ts
# lines 77 (chat log entry), 201, 203, 209, 211 (systemPrompt body)

tail -20 ~/.claude/PAI/PULSE/logs/telegram/chat-log.md
# shows literal {{DA_NAME}} / {{PRINCIPAL_NAME}} in entries

Suggested fix

Either substitute the placeholders at module init (read identity from PAI/USER/DA_IDENTITY.md / PRINCIPAL_IDENTITY.md like the installer does for other files), or replace the placeholder strings with abstract role labels — "the DA" / "the principal" — since the system-prompt context is functional, not display.

Note: #1135's installer-side fix won't reach this code path because the strings are in TypeScript source, not in PAI_SYSTEM_PROMPT.md. This needs source-code substitution (or a build-time codegen step), not just a fix in engine/actions.ts.

---

Environment

PAI v5.0.0, Bun 1.3.9, macOS, claude-agent-sdk 0.1.x.

[wojteksbt]

I’ve just been testing the Telegram integration, and at some point it got stuck, using up my entire 5x 5h limit and 43$ of the extra usage, so better be careful.

[catchingknives]

Confirmed independently — same numTurns: 0 / cost: 0 short-circuit pattern hit me on a long-lived Pulse process. Opened #1284 implementing your suggested Option A — drop resume as a minimal 12-line diff. The in-prompt history at lines 180–188 already carries the last 10 exchanges, so the SDK-side resume is the redundant channel.

For visibility this is also adjacent to #1281 (the v2 telegram rewrite), which addresses the same symptom by retry-with-fresh-session while keeping resume. #1284 is offered as the smaller surgical alternative aligned with the Option A you proposed here — maintainer's call which (or whether both) lands.

[ryan-baum]

I'm not sure the root cause is the SDK, I believe it's a UserPromptSubmit hook blocking the prompt before the model ever runs.

I hit the same failure on a long-lived Pulse instance (PAI v5.0.0, Telegram module) and traced it to ground. The diagnosis here is close, the double history channel is real and load-bearing, but the mechanism is different, and it changes which fix is correct.

The actual chain

1. telegram.ts runs the SDK with settingSources: ["user", "project"], which loads user-level hooks — including hooks/RepeatDetection.hook.ts (UserPromptSubmit) — into every bot session.
2. RepeatDetection.hook.ts compares each prompt to the previous one (Jaccard similarity over bi/trigrams, state in PAI/MEMORY/STATE/last-prompt.json) and on ≥60% similarity writes to stderr and calls process.exit(2) (lines 107–117).
3. For UserPromptSubmit hooks, exit code 2 blocks the prompt entirely — it never reaches the model, and stderr is routed to the terminal user, which in a headless bot is nobody. The session ends with exactly the signature in this issue's receipts: numTurns: 0, cost: 0, empty result, a few seconds duration.
4. The ≥60% similarity is manufactured by telegram.ts itself: every prompt is Previous conversation:\n{last 10 messages}\n\nPrincipal's new message: {text} (line 187). Consecutive prompts share the rolling history block, so similarity is dominated by the template, not by what the user typed.

Why short messages fail and long ones pass

That's just the Jaccard math, and the table in this issue fits it exactly: a 998-char message contributes enough new trigrams to dilute the shared history block below 0.6; "Agreed" contributes almost nothing, so the constructed prompt is nearly identical to the previous one → blocked. The SDK never "sees the new message as redundant against its transcript" — as far as I can tell there is no such SDK behavior. The model is never called at all.

Verify in 30 seconds

The session transcript records the block explicitly. For anyone hitting this:

grep -o '"UserPromptSubmit operation blocked by hook[^"]*' \
  ~/.claude/projects/*/<your-bot-session-id>.jsonl

Entries look like:

UserPromptSubmit operation blocked by hook:
[~/.claude/hooks/RepeatDetection.hook.ts]: ⚠️ REPEAT DETECTION: This message is 96% similar to the previous message...

On my instance, every fallback response across four days correlated 1:1 with one of these entries (13/13, similarity scores 60–98%) — including messages whose raw text shared almost nothing with the previous message. The history block did all the matching.

Why it's intermittent and seems to self-heal

The hook's state file is global but compared per session-id: any interleaved Claude session (terminal, cron) overwrites last-prompt.json with its own session id, so the bot's next message sees a mismatch and passes. After two consecutive bot messages it re-blocks. That's the "works in flow, then everything fails, then mysteriously recovers without a restart" pattern.

Implications for the open fixes

• fix(hooks): RepeatDetection injects warning via stdout, not stderr+exit 2 #1291 / fix(RepeatDetection): use stdout+exit 0 to inject warning as additionalContext #1306 are the real fix for the blocker — and not just for Telegram. The hook's own docstring says it intends to inject a warning into the model's context; stdout + exit(0) is that behavior. As written, the warning has never reached the model in any channel (in a terminal, exit-2 blocks the prompt and shows the warning to the human), and every SDK surface (the iMessage module ships in v5 with the same prompt-building pattern — imessage.ts lines 152/173, with "local" in its settingSources as well) silently drops prompts.
• fix(pulse/telegram): drop SDK session resume to prevent empty responses #1284 (drop resume) works by accident, not for the stated reason: without resume, each message gets a fresh session id, so the hook's same-session guard skips the comparison entirely. The symptom disappears, but the cause stays armed for every other channel, and you trade away SDK session continuity to dodge it. The minimal telegram-side fix is the inverse: keep resume, and prepend history only when starting a fresh session — the prepend is redundant when resuming, and that redundancy is what manufactures the similarity.
• Two cheap hardening additions, whichever PR merges: log the result subtype on non-success plus any non-init system messages (the block was invisible because line 262 only handles subtype === "success"), and clear lastSessionId when fullText comes back empty so one bad turn can't poison the next.
• Bug: Telegram bot fails on second message in headless/systemd mode — session resume always errors #1288 looks genuinely separate (session files not persisted in headless mode → resume errors with "No conversation found") and is worth keeping distinct from this one.

Running the conditional-embed + warn-not-block + observability combination in production since today: failure mode gone, and pre-model blocks now show up in Pulse logs directly. Happy to share the diff if useful.

[jmmarkiewicz]

Confirming your chain from a second instance — and thank you, this is the correct root cause.

Verified here (PAI v5.0.0, Bun 1.3.x, macOS):

1. hooks/RepeatDetection.hook.ts matches your description exactly: Jaccard over trigrams, 0.6 threshold, process.exit(2) after a stderr write — while the hook's own docstring says its intent is to "inject a high-priority WARNING" into context. The implementation never matched the intent on any surface.
2. Your grep reproduces on our transcripts — including on a surface neither of us had named: harness <task-notification> prompts (background-task completions) were being blocked at 62–63% similarity. Those are repetitive by construction, so the hook was silently eating them. Your point that this is "not just Telegram" is, if anything, understated.
3. Our Telegram module has since diverged locally so I can't re-test the original repro surface, but given (1)+(2) I consider the SDK-short-circuit theory in my original report withdrawn — the receipts table fits your Jaccard-dilution explanation better than my own.

We've applied warn-not-block locally (stdout hookSpecificOutput.additionalContext JSON + exit 0) and verified the warning reaches context while the prompt proceeds. +1 to #1291/#1306 as the real fix, and to your observability hardening suggestions — logging non-success subtypes would have made this a one-day diagnosis instead of a month.