[Anthony Kim (anthonykim1)]

• Add IPty.setParentWindow(handle), backed by ConptyReparentPseudoConsole from the bundled conpty.dll. The window becomes the owner of the console window, so dialogs that console apps parent to the console window or its owner, like the Connect-AzAccount sign-in picker, open in front of the host instead of behind it.
• Don't defer it until the pty is ready, since the pseudoconsole already exists. Called right after spawn(), the request is sent before the shell launches, because connect() waits for the conout worker. Hosts call it again when the terminal moves to another window.
• Return whether the request was sent; ConPTY applies it asynchronously. It's false once the pseudoconsole is closed, and always false unless on Windows with useConptyDll, since in-box ConPTY has no reparent API.
• Take the handle as a Buffer the size of an HWND, the way Electron's BrowserWindow.getNativeWindowHandle() returns it, so hosts can pass that Buffer directly. Throw for anything else.
• Null the HPCON in PtyKill so it's only closed once, and skip resize, clear, and reparent after that, since the baton outlives the pseudoconsole until the exit thread erases it.
• Add Windows tests for the owner when set right after spawn() and while the shell runs, the no-op once the pseudoconsole is closed, and invalid handles. Extend the Windows ConPTY backend data race in ptyHandles can crash in remove_pty_baton #921 race test to call setParentWindow.
• Keep setParentWindow optional in the public typings, so existing IPty implementations keep compiling. VS Code adopts this in Parent the ConPTY console window to the VS Code window vscode#342784.
• Re-enabling the host window when a modal dialog's process dies is tracked in Re-enable the parent window when a modal dialog's process dies #996.

---

Inspirations from:

• PtyReparent's argument checks, g_ptyHandlesMutex lookup, and conpty.dll GetProcAddress call are copied semantically from PtyClear, with the signature from the bundled conpty.h.
• TryGetWindowHandle is copied from deepak1556's review suggestion, and takes the handle in the format win.getNativeWindowHandle() returns.
• Reparenting before the client launches, and again on window moves, comes from Windows Terminal's ConptyConnection::Start and ConptyConnection::ReparentWindow.
• The null-HPCON guard follows from PtyKill freeing the pseudoconsole while the baton lives until the exit thread erases it.
• The race coverage extends the existing Regression for #921 test.

[Anthony Kim (anthonykim1)]

Findings are inline: one p1 on the native guard, the rest p2.

• PtyReparent relies on JS-side bookkeeping (_isKilled) to avoid writing through a freed PseudoConsole*; the native entry should be safe on its own.
• The new export swallows every failure (HRESULT, missing export, lossy BigInt), so callers can't tell whether the owner was applied.
• The #921 race extension never reaches PtyReparent.
• IPty.setParentWindow as a required member breaks IPty implementers in a 1.x minor, and the @param example doesn't match the signature.
• conptyParentWindow is applied from the WindowsTerminal constructor after the agent already started the pty; a throw there leaks the agent.

[Anthony Kim (anthonykim1)]

Pushed 909b13e for the review. All six threads are addressed and resolved.

It also included a fix from the VS Code review (microsoft/vscode#342784 (comment)) that re-enabled the parent window when a modal dialog died with the shell. That has since moved out of this PR to #996.

Verified on Windows 11:

• The parent-window and Windows ConPTY backend data race in ptyHandles can crash in remove_pty_baton #921 tests pass in both useConptyDll modes (12/12).
• Full suite: 65 passing. The only failures are the two "should kill the process tree" timeouts, which also fail on main on this machine.
• No new compiler warnings, and npm run lint is clean.
• I ran this branch end to end in a VS Code dev build, see Parent the ConPTY console window to the VS Code window vscode#342784.

[Anthony Kim (anthonykim1)]

cc Dustin L. Howett (@DHowett) Robo (@deepak1556)

[Dustin L. Howett (DHowett)]

/cc Leonard Hecker (@lhecker) as well

[Anthony Kim (anthonykim1)]

Pushed f164f25 after another pass over the review, then 95ed9a4 to keep this PR to one new API, cd33f21 for the handle review, and f699175 to take the handle as a Buffer:

• setParentWindow() is the only new API. conptyParentWindow is gone: hosts call setParentWindow() right after spawn(). It isn't deferred, and connect() waits for the conout worker, so the request is sent before the shell launches.
• Re-enabling the parent window when a modal dialog's process dies moved to Re-enable the parent window when a modal dialog's process dies #996, with the implementation from f164f25.
• The handle is a Buffer the size of an HWND, the way Electron's getNativeWindowHandle() returns it; anything else throws.
• kill() never closes the pseudoconsole twice, and setParentWindow returns whether the request was sent.
• The parent window tests kill and wait for every pty they start, so a failing test can't keep mocha from exiting.

Verified locally at f699175:

• Parent window and Windows ConPTY backend data race in ptyHandles can crash in remove_pty_baton #921 tests: 10 passing across both useConptyDll modes. Full suite: 63 passing; the 2 failures are the existing should kill the process tree timeouts from my slow PowerShell profile. Lint is clean.
• In a VS Code dev build with Parent the ConPTY console window to the VS Code window vscode#342784: new terminals are owned by VS Code, the real Connect-AzAccount picker opens in front of it, and the owner follows a terminal into a new window and across a reload.

(generated by copilot)