[Bug] WSL2 broker authentication corrupts stdout

[embetten]

Library version used

4.77.1.0

.NET version

net 8 desktop application
MSAL.NET: 4.77.1.0
Microsoft.Identity.Client.NativeInterop: 0.19.4 (also reproduced with 0.20.4)
Platform: WSL2 (Ubuntu) on Windows 11

Scenario

PublicClient - desktop app

Is this a new or an existing app?

The app is in production, and I have upgraded to a new version of MSAL

Issue description and reproduction steps

When using Microsoft.Identity.Client with broker authentication (via Microsoft.Identity.Client.NativeInterop / libmsalruntime.so) inside WSL2, the native library's subprocess execution causes uncontrolled writes to the calling process's stdout, corrupting any structured protocol that communicates over stdout (e.g., NuGet plugin protocol, Git credential protocol).

This is the same class of bug as #2427 (fixed in PR #2507), where xdg-open wrote browser output to the calling process's stdout. In that case, MSAL .NET fixed it by redirecting StandardOutput/StandardError on the child Process. However, this new instance is in the native C++ layer (libmsalruntime.so), not in managed .NET code.

Potential Root Cause

libmsalruntime.so uses popen() to execute the WSL proxy (msal.wsl.proxy.exe) and wslinfo for broker IPC commands (GetAccounts, AcquireTokenSilent, etc.) and proxy path discovery.

When popen() runs a Windows .exe via WSL2 interop, the WSL2 interop bridge process resolves /proc/PARENT/fd/1 at write time to find where to send the proxy's output. This resolves to the calling dotnet process's fd 1 (e.g., the NuGet plugin pipe), not the pipe created by popen(). The result is that broker proxy output is written directly to the host process's stdout, corrupting any structured protocol.

Reproduction

Any .NET application running in WSL2 that:

1. Communicates with a parent/host process over stdout using a structured protocol (JSON, line-delimited messages, etc.)
2. Uses Microsoft.Identity.Client with publicclient broker authentication with WIndowns and Linux brokers enabled (WAM via the WSL proxy)
3. Triggers a broker call that invokes msal.wsl.proxy.exe (e.g., AcquireTokenSilent when no cached session token is available) will experience stdout corruption. The broker proxy's IPC responses leak into the application's stdout stream, breaking the structured protocol.

Question: Where Should This Be Fixed?

Given the precedent of #2427 / PR #2507, where MSAL .NET took responsibility for preventing child process stdout pollution:

1. Should this be fixed in libmsalruntime.so (NativeInterop)? The bug is in the native C++ code that uses popen(). This seems like the right layer since consumers of Microsoft.Identity.Client.NativeInterop shouldn't need to worry about stdout corruption.
2. Should Microsoft.Identity.Client (.NET) add a managed workaround? For example, could MSAL .NET redirect its own stdout before calling into NativeInterop on WSL2? This would be fragile and race-prone with concurrent protocol writes.
3. Should consumers handle this themselves? This puts the burden on every NuGet plugin, Git credential helper, and other stdout-protocol tool that uses MSAL broker auth on WSL2.

We believe (1) is the correct fix location.

Relevant code snippets

Expected behavior

stdout does not have unexpected output for stdin/stdout processes that invoke WSL Linux broker silent auth

Identity provider

Microsoft Entra ID (Work and School accounts and Personal Microsoft accounts)

Regression

I cant tell if this is a MSAL regression or a bug that was always in the linux broker - but only surfaced when we fixed brokered silent auth in the artifacts-credprovider microsoft/artifacts-credprovider#664

Solution and workarounds

We can opt out of linux broker silent auth if we detect wsl ? But we would like to offer WAM redirection in linux where posible.