[BUG] Background-task notifications and task IDs leak between concurrent Claude Code sessions in the same working directory

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When two Claude Code sessions run in the same repo, a long-lived background task started in Session A can appear (as a failure notification) in Session B — even when Session B never spawned that task. Subsequent attempts by Session B to "restart" what it thinks is its own task collide with Session A's still-running process. Port-based monitors can't distinguish ownership, producing contradictory signals.When two Claude Code sessions run in the same repo, a long-lived background task started in Session A can appear (as a failure notification) in Session B — even when Session B never spawned that task. Subsequent attempts by Session B to "restart" what it thinks is its own task collide with Session A's still-running process. Port-based monitors can't distinguish ownership, producing contradictory signals.

Confused debugging; one session can unintentionally try to manage another's processes; monitor signals become unreliable. In the worst case, a "restart" by the wrong session can terminate work owned by another.

What Should Happen?

Each session has an isolated task ID space and notification stream. A session should never receive task-status events for processes it didn't spawn. Tools to inspect "my own" tasks shouldn't include other sessions'.

Error Messages/Logs

Steps to Reproduce

1. Open two Claude Code sessions in the same project directory.
2. Session A runs dotnet run --project ... as a background task; Claude Code assigns task ID X.
3. Time passes; Session A becomes idle.
4. In Session B (or via OS), the process backing task X is killed or replaced.
5. Session A's next turn receives a "task X failed (exit 1)" notification — for a task it didn't kill.
6. Session A spawns a "replacement" task; it collides on port with Session B's running process. The new task reports "failed exit 127", but a port-listening probe shows the port is bound (by the other session), making behavior look contradictory.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.52 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_