Stop hook output from one session leaks into another session's context
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
- Run two Claude Code sessions in parallel (e.g., in separate terminal windows, same repo with worktrees)
- Have the ralph-loop plugin enabled globally (
~/.claude/settings.json) - One session has an active ralph-loop (state file at
.claude/ralph-loop.local.mdin its worktree) - 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
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗