Stop hook output from one session leaks into another session's context

Resolved 💬 3 comments Opened Feb 28, 2026 by rtc Closed Mar 3, 2026

Bug Description

Stop hook output from one Claude Code session appears as a <system-reminder> in a different, unrelated Claude Code session. This causes the receiving session to act on instructions meant for the other session.

Steps to Reproduce

  1. Run two Claude Code sessions in parallel (e.g., in separate terminal windows, same repo with worktrees)
  2. Have the ralph-loop plugin enabled globally (~/.claude/settings.json)
  3. One session has an active ralph-loop (state file at .claude/ralph-loop.local.md in its worktree)
  4. When that session's stop hook fires and blocks exit (feeding the prompt back), the hook's blocking output appears in the other session as a system-reminder

Observed Behavior

Session A (working on workflow tooling) received this system-reminder mid-conversation:

<system-reminder>
Stop hook blocking error from command: "${CLAUDE_PLUGIN_ROOT}/hooks/stop-hook.sh": 
now lets work through each porsche dealer site until we have all of the listings accurately extracted
</system-reminder>

The "porsche dealer site" text was the ralph-loop prompt from Session B. Session A had no ralph-loop active and was working on an unrelated task.

Session A then started acting on Session B's instructions (began researching Porsche dealer extraction) until the user noticed and stopped it.

Expected Behavior

Hook output should be scoped to the session that triggered the hook. One session's stop hook output should never appear in another session's context.

Environment

  • macOS (Darwin 25.3.0)
  • Multiple sessions via persistent worktrees (same repo)
  • Ralph-loop plugin enabled globally: "enabledPlugins": {"ralph-loop@claude-plugins-official": true}
  • Claude Code with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Impact

  • Cross-session instruction injection: One session acts on another's prompts
  • Wasted work: The receiving session may spend significant time/tokens on the wrong task before the user notices
  • Confusing UX: The leaked message appears as a legitimate system-reminder, so the agent treats it as authoritative

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗