Telegram plugin (bun server.ts) accumulates infinitely when Stop hook spawns claude -p subprocesses

Bug Report

Summary

When a Stop hook calls claude -p (headless/non-interactive mode), the subprocess also triggers the Stop hook upon completion, causing infinite recursion. Each spawned subprocess starts a new instance of the Telegram plugin (bun server.ts), resulting in runaway process accumulation.

Environment

• OS: macOS (Darwin 25.4.0)
• Plugin: telegram@claude-plugins-official
• Hook type: Stop

Steps to Reproduce

1. Configure a Stop hook that calls claude -p <prompt> --output-format json (e.g., an auto-memory summarization script)
2. End a Claude Code session
3. The Stop hook fires → spawns claude -p subprocess
4. That subprocess ends → triggers Stop hook again → spawns another claude -p
5. Repeat indefinitely

Observed Behavior

• 38 bun server.ts (Telegram plugin) processes running simultaneously
• 23 claude processes running simultaneously
• System resource exhaustion over time

Root Cause

Headless claude -p invocations triggered by a Stop hook themselves trigger the Stop hook upon completion, creating an unbounded recursive chain. Each claude subprocess spawned this way also initializes all configured plugins (including Telegram), starting a new bun server.ts per invocation.

Workaround

Added an environment variable guard in the hook script:

import os
if os.environ.get("CLAUDE_MEMORY_HOOK_RUNNING") == "1":
    return  # prevent recursion

# when spawning claude subprocess:
env = {**os.environ, "CLAUDE_MEMORY_HOOK_RUNNING": "1"}
subprocess.run([CLAUDE_BIN, "-p", prompt, ...], env=env)

Suggested Fix

• Provide a built-in environment variable (e.g., CLAUDE_HOOK_DEPTH or CLAUDE_HEADLESS) so users can detect subprocess context
• Or have headless (-p) mode skip Stop hooks by default, since headless invocations are typically not interactive sessions
• Or document this recursion risk prominently for Stop hooks that spawn subprocesses