Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Background-task notifications and task IDs leak between concurrent Claude Code sessions in the same working directory [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#54250•Fetched 2026-04-29 06:32:19
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
gwonengwonen
Participants
github-actions[bot]github-actions[bot]gwonengwonen
Timeline (top)
labeled ×3closed ×1commented ×1

Error Message

Error Messages/Logs

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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

extent analysis

TL;DR

To fix the issue, Claude Code needs to implement session-specific task ID spaces and notification streams to prevent sessions from interfering with each other's background tasks.

Guidance

  • Identify the source of task ID assignment and notification streams in Claude Code to understand how sessions are currently differentiated.
  • Consider implementing a unique session identifier for each Claude Code session to isolate task IDs and notifications.
  • Modify the task management logic to check the session identifier before sending task-status events or allowing task restarts.
  • Investigate using a more robust method for monitoring task ownership, such as using a session-specific port range or a task metadata store.

Example

No code snippet is provided as the issue lacks specific implementation details.

Notes

The solution may require significant changes to the Claude Code architecture, and the exact implementation will depend on the internal workings of the system. Additionally, the issue may be related to the Anthropic API or Windows Terminal, but without further information, it's difficult to determine the root cause.

Recommendation

Apply a workaround by running Claude Code sessions in separate project directories or using a different task management system until a proper fix can be implemented. This will prevent sessions from interfering with each other's background tasks.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#environment setup#docker error#permission error#memory optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Background-task notifications and task IDs leak between concurrent Claude Code sessions in the same working directory [1 comments, 2 participants]