Assistant hallucinated unsolicited Telegram invite URLs in reply
What happened
In a session resume, Claude Sonnet 4.6 (1M context) generated two unsolicited Telegram group invite URLs in an assistant reply. The reply had no prompt asking for links, no tool call, no web source - the URLs were invented wholesale and presented as if they belonged in the response.
Verbatim assistant output (from session transcript):
Understood. Read the docs.
<https://t.me/+cj6NeADdwHxiNDk1>
<https://t.me/+iFG16YiGeX0wZjE1>
The user's prompt immediately before was a session-continuation handoff note - no Telegram reference, no URL request, no group context.
Why this is serious
Telegram t.me/+<hash> URLs are private group join links. An unsuspecting user clicking an LLM-generated link:
- May be joined to an attacker-controlled group (phishing, scam, CSAM, credential harvesting)
- Exposes their Telegram identity to whoever controls the link
- Establishes trust with a malicious party ("my AI assistant recommended this")
This is a plausible attack vector if a model can be induced (via training data poisoning, prompt injection anywhere upstream, or spontaneous hallucination as observed here) to emit clickable links to third-party platforms.
Verification
- No
t.me/or "telegram" string in user settings, hooks, skills, agents, scripts, or any project config - Telegram plugin is installed on disk but
enabledPlugins.telegramis false - its MCP server was not running - No UserPromptSubmit hook or SessionStart hook injected the URLs
- URL fragments
cj6NeADdwHxiNDk1andiFG16YiGeX0wZjE1appear only inside this session's own assistant-generated transcript - nowhere else on disk
The URLs originated inside the model's output, not from any injection.
Requested fixes
- Add a refusal/filter layer for LLM-generated links to high-risk platforms (Telegram, Discord invite links, pastebins, URL shorteners) when no user prompt and no tool source justifies them
- Log and alert on anomalous assistant output containing URLs to messaging-platform invite patterns
- Root-cause investigation on why a session-continuation handoff turn emitted these specific URLs - training data contamination check, especially for Sonnet 4.6
Environment
- Claude Code CLI
- Model: Sonnet 4.6 (1M context)
- Platform: darwin 25.4.0
- Session type: resumed (session-start hook fired, handoff note in first user message)
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗