Ralph-loop: state file needs session scoping to prevent cross-terminal interference

Problem

The ralph-loop plugin stores its state in .claude/ralph-loop.local.md in the project root. This file is shared by all Claude Code sessions in the same project directory, which causes serious interference when running an interactive session alongside an active ralph-loop.

What happens

1. Terminal A starts ralph-loop for a feature → creates .claude/ralph-loop.local.md with active: true
2. Terminal B opens in the same project for interactive work
3. The ralph-loop stop hook fires after every Claude response in Terminal B
4. The stop hook reads the shared state file, sees active: true, and tries to re-feed the ralph-loop prompt into Terminal B
5. Terminal B's Claude dismisses it, but the stop hook fires again on that response

This creates a destructive loop in Terminal B:

• The iteration counter increments in the shared state file, burning through Terminal A's iteration budget
• Every response in Terminal B triggers another stop hook cycle, filling the context window with noise
• Eventually forces the user to manually interrupt
• The ralph-loop session thinks it ran N iterations when most were wasted in Terminal B

Reproduction

1. Open two terminals in the same project directory
2. In Terminal A: start a ralph-loop (/ralph-loop:ralph-loop "some prompt" --max-iterations 20)
3. In Terminal B: start an interactive Claude session and ask it anything
4. Observe the stop hook firing repeatedly in Terminal B after every response

Expected behavior

Each ralph-loop session should only affect the terminal/session that started it. Interactive sessions in the same project directory should not be impacted.

Suggested fix

Scope the state file per session. For example:

• Include a session ID or PID in the filename: .claude/ralph-loop-<session-id>.local.md
• Or use an environment variable / process-scoped mechanism so the stop hook only activates in the session that started the loop
• The stop hook should check whether this session owns the active loop before intercepting

Workaround

Currently the only workaround is to avoid running interactive Claude sessions in the same project directory while ralph-loop is active (e.g., use git worktree for a separate working directory).

Environment

• Claude Code v2.1.45
• macOS (Darwin 25.2.0)
• ralph-loop plugin via ralph-loop@claude-plugins-official