[BUG] Preview pane spawned by background session opens in foreground session and stays there

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 running two Claude Code sessions simultaneously on the same project, a preview pane triggered by a background session (B) incorrectly opens in the foreground session (A). The pane then remains bound to session A — it persists when A has focus and disappears when switching to B, the session that actually owns it.

Actual Behavior

Session B triggers a preview pane while backgrounded.
The pane opens in session A (foreground) instead of session B.
The pane is permanently associated with session A's window — visible when A has focus, gone when B has focus.
Session B never shows its own preview pane.

What Should Happen?

The preview pane opens in the session that triggered it (session B), regardless of which session has focus.
Switching focus between sessions has no effect on preview pane visibility or ownership.

Error Messages/Logs

Steps to Reproduce

Open Claude Code — this becomes session A.
Open a second Claude Code session on the same project — this becomes session B.
Give focus to session A (make it the foreground session).
In session B (background, no focus), trigger an action that opens a preview pane.
Observe: the preview pane opens in session A, displaying session B's content.
Switch focus to session B.
Observe: the preview pane disappears.
Switch focus back to session A.
Observe: the preview pane reappears in session A.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.78 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

The preview pane is likely being rendered using the active window handle (foreground HWND) at creation time rather than the handle belonging to the spawning session. This is a window-ownership bug specific to the Windows multi-session scenario — the pane creation call needs to target the session's own window context, not the currently focused one. (according to Claude).