[Triage] MSBuild Server coherence gaps across MSBuild and the .NET SDK

[JanProvaznik]

Purpose

Parking a detailed cross-repository audit for later triage. This is not asserting that every item needs an immediate fix; it separates proven behavioral defects from design risks, documentation drift, and missing coverage.

The audit was independently repeated with GPT-5.6 Sol and Claude Opus 4.8, then disagreements were resolved against the source.

Audited revisions:

• MSBuild: 93022af5849a9c3023d40cf7a97f54d15f43a2f6
• .NET SDK: de83a9ce2ac64704b5b0ef5b175dfcaec0f0d08c

Executive summary

Verdict: partially coherent.

The MSBuild-side transport is reasonably coherent: one compatible client at a time talks to a reusable entry-node process keyed by an MSBuild handshake; requests carry arguments, environment, working directory, culture, console capabilities, telemetry, and output is returned over packets.

The cross-layer product contract is not coherent:

• The SDK presents global controls such as --disable-build-servers and dotnet build-server shutdown.
• MSBuild implements a family of narrowly keyed, opportunistic, single-client processes.
• Request-scoped intent such as disabled, persistent, ephemeral, /mt, GC profile, and interactive behavior is not represented in server identity.
• Shutdown cannot enumerate the fleet that the SDK wording implies.
• Several process-lifetime states are not reset between requests.

The central design mismatch is:

Request-scoped intent is layered onto a launch-scoped server identity.

That mismatch directly causes the short-lived-server reuse bug, sticky GC behavior, opt-out disagreement, shutdown scope problems, and interactive input ambiguity.

Actual implementation contract

Enablement

• The SDK enables the server by default by injecting MSBUILDUSESERVER=1 when the user has not already set it:
  MSBuildForwardingAppWithoutLogging.cs#L20-L25,
  #L101-L107.
• Standalone MSBuild enables it only for MSBUILDUSESERVER=1, or implicitly for /mt when the variable is unset/empty. Any other non-empty value opts out:
  XMake.cs#L515-L558.
• /nodeReuse:false normally disqualifies the server. /mt is a special case: it still uses a server but asks it to terminate after the build:
  XMake.cs#L452-L482.

Identity and compatibility

The server pipe is MSBuildServer-{handshake hash}:
OutOfProcServerNode.cs#L180-L187.

The key includes handshake options, tools-root-derived salt, and full MSBuild file version:
ServerNodeHandshake.cs#L20-L54,
Handshake.cs#L85-L125.

Architecture and Windows elevation are represented:
CommunicationsUtilities.cs#L625-L681.

The key does not represent:

• persistent versus ephemeral intent;
• /mt;
• GC profile;
• interactive/input requirements;
• Windows session ID (ServerNodeHandshake explicitly passes includeSessionId: false);
• a discoverable instance identifier.

Lifetime and concurrency

• One pipe connection is accepted at a time:
  NodeEndpointOutOfProcBase.cs#L246-L285.
• A busy server causes immediate in-process fallback rather than queueing:
  MSBuildClient.cs#L225-L238.
• An idle endpoint waits for MSBUILDNODECONNECTIONTIMEOUT, 15 minutes by default, before terminating:
  CommunicationsUtilities.cs#L42-L78,
  NodeEndpointOutOfProcBase.cs#L380-L408.

Request boundary

The request carries command-line arguments, startup directory, complete environment, culture/UI culture, console configuration, telemetry, and ShutdownAfterBuild:
ServerNodeBuildCommand.cs#L16-L112.

There is no stdin channel. stdout/stderr are transported with ServerNodeConsoleWrite:
ServerNodeConsoleWrite.cs#L6-L47.

Findings

1. High: a "short-lived" /mt /nodeReuse:false request can reuse and terminate a resident server

Classification: proven behavioral defect.

shutdownServerAfterBuild is computed as request state:
XMake.cs#L452-L482.

However, the client first checks for and connects to any existing server with the same handshake:
MSBuildClient.cs#L210-L238.

ShutdownAfterBuild is only included in the later build-command packet:
MSBuildClient.cs#L601-L642.

The server then exits after that build:
OutOfProcServerNode.cs#L461-L485.

Consequences

1. A no-reuse request can consume process/static/cache state from a persistent server.
2. It then destroys that server, affecting subsequent commands that expected it to remain warm.
3. SDK --disable-build-servers does not provide its documented "ignore persistent servers" behavior when /mt is enabled.
4. The documentation explicitly calls this a "fresh process," which is not guaranteed:
   MSBuild-Server.md#L14-L22.

Repro sketch

1. Enable/warm the persistent server with a normal build.
2. Run the same MSBuild installation and handshake with /mt /nr:false.
3. Observe the second build execute in the first server PID.
4. Observe that PID exit afterward.

Coverage hole

The short-lived test explicitly shuts down the existing server before running, so it only proves the cold-start case:
MSBuildServer_Tests.cs#L201-L222.

Suggested direction

Ephemeral requests need a separate identity:

• unique pipe/nonce per request; or
• an ephemeral bit in the handshake plus a guarantee that it never attaches to persistent instances.

2. High: dotnet build-server shutdown --msbuild reports success after MSBuild reports failure

Classification: proven cross-layer defect.

MSBuild shutdown returns false when:

• the server is busy;
• connection fails;
• the shutdown packet cannot be sent;
• the final protocol result is not successful.

Evidence:
MSBuildClient.cs#L270-L321.

BuildManager.ShutdownAllNodes() discards that boolean:
BuildManager.cs#L1491-L1500.

The SDK abstraction is void:
MSBuildServer.cs#L10-L19.

The command treats any non-faulted task as success:
BuildServerShutdownCommand.cs#L51-L80.

Repro sketch

1. Keep a matching server busy with a long-running build.
2. Run dotnet build-server shutdown --msbuild.
3. TryShutdownServer returns false after the 250 ms busy retry.
4. The SDK prints success and exits 0.
5. The server remains alive.

Suggested direction

Expose a typed result, for example:

• Stopped
• NotFound
• Busy
• ConnectionFailed
• ProtocolFailed
• TimedOut

The SDK should return nonzero when a selected instance remains running.

3. High: SDK shutdown only addresses one handshake while presenting broad/global semantics

Classification: proven product-contract defect.

The SDK provider emits one synthetic controller and does not enumerate real MSBuild instances:
BuildServerProvider.cs#L23-L30.

Shutdown constructs the current MSBuild client's one handshake:
MSBuildClient.cs#L278-L283,
#L639-L642.

The following independently create different identities:

• MSBuild file version;
• tools root / SDK installation path;
• architecture;
• Windows elevation;
• MSBUILDNODEHANDSHAKESALT.

Therefore a command using SDK B cannot generally shut down a server launched by SDK A. Running the command from a differently selected global.json, dotnet root, architecture, elevation, or test salt can return success while the other server remains.

The SDK documentation says:

Shuts down build servers that are started from dotnet. By default, all servers are shut down.

dotnet-build-server.1#L36-L55

Suggested direction

Use discoverable per-user instance descriptors containing at least:

• PID;
• pipe;
• protocol/version;
• tools root;
• architecture;
• elevation;
• session/user scope;
• persistent/ephemeral mode;
• owned child processes;
• current state.

Then define whether shutdown means "current compatible server" or "all current-user MSBuild servers."

4. High: DOTNET_CLI_USE_MSBUILD_SERVER=false is not an authoritative opt-out for /mt

Classification: proven cross-layer defect.

When DOTNET_CLI_USE_MSBUILD_SERVER is false, the SDK merely declines to set MSBUILDUSESERVER=1:
MSBuildForwardingAppWithoutLogging.cs#L20-L25,
#L101-L107.

MSBuild interprets unset/empty plus /mt as implicit server enablement:
XMake.cs#L531-L558.

The decision table tests this behavior:
XMake_Tests.cs#L3280-L3300.

Repro sketch

DOTNET_CLI_USE_MSBUILD_SERVER=0 dotnet msbuild project.proj -mt

With no explicit MSBUILDUSESERVER, the server is still selected.

This can also occur without a visible /mt argument through MSBUILDFORCEMULTITHREADED=1 or response files.

Suggested direction

When the SDK opt-out is false and the user has not explicitly set MSBUILDUSESERVER, inject:

MSBUILDUSESERVER=0

Define precedence when both variables are explicitly present.

5. High: interactive builds are server-eligible, but the protocol has no stdin

Classification: proven unsupported-behavior gap; real-world prevalence requires research.

Interactive mode is not one of the server-incompatible switches:
XMake.cs#L441-L450.

There is an integration test requiring the server to start for -interactive, but it verifies only the PID/lifetime:
MSBuildServer_Tests.cs#L425-L443.

The request protocol has no stdin packet:
ServerNodeBuildCommand.cs#L16-L112.

Only stdout/stderr are returned:
ServerNodeConsoleWrite.cs#L6-L47.

For a reused server, even inheriting the original launcher's stdin could not bind it to the current client terminal.

Possible directions

1. Make interactive builds server-ineligible until input is supported.
2. Define a bidirectional input protocol with cancellation and secret-input behavior.
3. Explicitly document that "interactive" only affects MSBuild/NuGet policy and does not promise Console.In.

Real-world task/logger usage of Console.Read* will be researched and added as a follow-up comment.

6. Medium: GC mode is sticky from the first cold launch

Classification: proven lifecycle/performance defect.

Server GC is injected only while launching a new /mt server:
MSBuildClient.cs#L543-L568.

GC mode is absent from the handshake:
MSBuildClient.cs#L639-L642,
ServerNodeHandshake.cs#L25-L34.

Therefore:

• normal build then /mt: /mt may use Workstation GC;
• /mt then normal build: the normal build keeps Server GC.

Existing tests isolate each case with a fresh handshake and never test transitions:
MSBuildServer_Tests.cs#L650-L706.

The documentation also says a non-/mt server "only orchestrates," but normal scheduling prefers the in-process node:
NodeManager.cs#L91-L105.

The standard server test's task executes in the server PID:
MSBuildServer_Tests.cs#L101-L117.

Suggested direction

Either:

• put GC profile in server identity; or
• choose one invariant server GC policy and document it.

7. Medium: reusable TaskHost sidecars are omitted from public shutdown

Classification: proven lifecycle gap.

Normal tidy build completion allows TaskHost reuse:
BuildManager.cs#L2421-L2437.

Public BuildManager.ShutdownAllNodes() shuts:

1. the MSBuild Server;
2. the regular NodeManager.

It does not invoke TaskHostNodeManager:
BuildManager.cs#L1491-L1500.

TaskHost shutdown exists separately:
TaskHostNodeManager.cs#L62-L77.

Impact

dotnet build-server shutdown --msbuild can leave nodemode-2 processes, loaded custom-task assemblies, and file handles alive until their own timeout.

Suggested direction

Define whether these are owned children of the server. If so, register and stop them as part of server shutdown.

8. Medium: concrete process state leaks between server requests

Classification: proven internal defects exposed by persistence.

Deferred logger messages accumulate

ResetBuildState() only resets parser state:
XMake.cs#L1498-L1505.

The static deferred-message list is retained:
XMake.cs#L1525-L1529.

Terminal-logger/environment decisions append messages every invocation:
XMake.cs#L2764-L2795,
#L2861-L2882.

Later builds copy the complete retained list:
XMake.cs#L2020-L2055.

This can create stale/duplicate diagnostics and unbounded list growth during server reuse.

Process priority is not restored

/lowPriority lowers the current server process:
XMake.cs#L2462-L2484.

A later normal request initializes its local lowPriority flag to false but never restores the server process to normal priority.

Suggested direction

Create an explicit per-request reset boundary covering all non-cache mutable state. Cache retention should be deliberate and separately enumerated.

This aligns with the still-open broader static-lifetime problem:
dotnet#12246

9. Low: cold-start launch coordination releases the mutex before launching

Classification: proven efficiency/race defect.

The launch mutex scope ends before process creation:
MSBuildClient.cs#L500-L525.

The process is launched afterward:
MSBuildClient.cs#L525-L578.

The server-side running mutex later ensures one process survives:
OutOfProcServerNode.cs#L110-L123.

This preserves eventual safety but permits duplicate cold launches, churn, and avoidable fallback under contention.

10. Medium/low: identity and session partitioning are underspecified

Classification: proven same-user cross-session coupling; cross-user impact is an OS-security design risk, not a proven exploit.

ServerNodeHandshake excludes Windows session ID:
ServerNodeHandshake.cs#L20-L22.

The base handshake otherwise documents session separation for RDP:
Handshake.cs#L111-L121.

Pipes are current-user secured:
NodeEndpointOutOfProcBase.cs#L246-L285.

Mutex names are machine-global and do not contain a user/session discriminator:
OutOfProcServerNode.cs#L180-L187.

The guaranteed behavior is that two Windows sessions for the same user share one server identity. Cross-user mutex interference depends on platform/default DACL behavior and needs a dedicated test before treating it as a security bug.

11. Documentation and command-surface drift

Wrong environment variable

MSBuild documentation says to use the nonexistent DOTNET_CLI_DO_NOT_USE_MSBUILD_SERVER:
MSBuild-Server.md#L5-L8.

The SDK implements DOTNET_CLI_USE_MSBUILD_SERVER; MSBuild implements MSBUILDUSESERVER.

Misleading "build from scratch" claim

SDK documentation claims --disable-build-servers disables all caching and forces a build from scratch:
dotnet-build.1#L153-L159.

The option only forwards:

• UseRazorBuildServer=false
• UseSharedCompilation=false
• /nodeReuse:false

CommonOptions.cs#L265-L271.

It does not clean outputs or disable ordinary MSBuild incremental behavior, NuGet caches, project-system caches, or every MSBuild invocation surface.

Incomplete command coverage

Some commands that invoke MSBuildForwardingApp, including package add/list and some Microsoft.Testing.Platform paths, do not expose the same per-command server-disable surface.

Stale "MSBuild Server V1" terminology

The SDK environment-variable documentation describes DOTNET_CLI_USE_MSBUILDNOINPROCNODE / MSBUILDNOINPROCNODE as "MSBuild Server V1":
dotnet-environment-variables.7#L533-L539.

This is a different worker-node behavior and makes the term "MSBuild Server" ambiguous.

Missing tests

Highest-value additions:

1. Warm persistent server followed by /mt /nr:false: assert a different PID, no warm-state reuse, and survival of the resident server.
2. Busy real server plus dotnet build-server shutdown --msbuild: assert nonzero exit and no success message.
3. Two SDK versions/tools roots/architectures/elevation states/salts: verify explicitly defined current/all shutdown semantics.
4. DOTNET_CLI_USE_MSBUILD_SERVER=0 plus /mt and MSBUILDFORCEMULTITHREADED=1.
5. GC transition matrix: normal -> /mt, /mt -> normal.
6. An interactive task that actually reads stdin, rather than checking only PID.
7. Server plus reusable TaskHost shutdown: assert all owned processes exit.
8. Two-request reset matrix for deferred diagnostics, process priority, telemetry, handlers, environment-derived traits, and retained caches.
9. Barrier-controlled concurrent cold launch.
10. Same-user multi-session and multi-user identity/security tests.
11. SDK command-schema/E2E matrix across every MSBuildForwardingApp consumer.

The existing SDK shutdown tests mock IBuildServer and therefore cannot detect the discarded false result:
BuildServerShutdownCommandTests.cs#L101-L158.

The MSBuild shutdown integration test is currently quarantined on Windows:
MSBuildServer_Tests.cs#L370-L403.

Proposed coherent target design

Explicit mode

Represent server intent as an enum rather than independent side effects:

Disabled
Persistent
EphemeralForMt

Explicit false must always beat implicit /mt enablement.

Typed identity

Identity should deliberately account for:

• tools path/version and protocol;
• runtime host;
• architecture;
• elevation;
• user/session;
• GC profile;
• persistent/ephemeral reuse class.

Ephemeral isolation

Ephemeral requests must never attach to or terminate persistent instances.

Registry-based discovery

Maintain per-user descriptors for real instance enumeration and reliable shutdown.

Typed shutdown

Return real results instead of collapsing everything to non-throwing success.

Owned child lifecycle

Track and shut down reusable worker and TaskHost children consistently.

Interactive contract

Either implement bidirectional stdin or make interactive invocations ineligible.

Per-build reset contract

Reset all non-cache mutable process state. Explicitly inventory which caches are intentionally retained and how they are invalidated.

Suggested triage/fix order

1. Preserve shutdown failures and stop printing false success.
2. Separate ephemeral and persistent server identities.
3. Make SDK/direct-MSBuild opt-outs authoritative.
4. Add real server discovery and define shutdown scope.
5. Include TaskHosts/owned children in lifecycle management.
6. Disable server for interactive builds pending stdin support.
7. Fix concrete per-request state leaks and launch locking.
8. Align command surfaces, documentation, and the test matrix.

Important non-findings / qualifications

• The process environment is replaced between builds; claiming that environment variables themselves simply leak from request A into request B is overstated. Static task/process state remains the broader risk.
• A busy server falling back rather than queueing is current policy, not itself a defect.
• Connection failure after dispatch must not blindly rerun the build, because doing so could duplicate side effects.
• MSBuildClientExitType.Success represents protocol completion, not necessarily a successful build result.
• Cross-user pipe hijacking is not established: pipe security is current-user-based. The mutex/user namespace question needs platform tests rather than speculation.
• Servers are not immortal: the default idle connection timeout is 15 minutes.

Open research item

The source proves that interactive builds have no stdin transport. A follow-up comment will investigate whether real public MSBuild tasks/loggers actually use Console.Read, Console.ReadLine, Console.ReadKey, Console.In, or direct standard-input APIs, and whether those usages run on the central/server node.

[JanProvaznik]

Follow-up research: are stdin-reading interactive tasks real?

Bottom line

Yes, direct stdin reads inside real shipped MSBuild tasks exist, but they are niche and concentrated in "pause/prompt/debug the build" helpers.

The stronger ecosystem conclusion is:

MSBuild interactivity is primarily an authorization/policy signal, not a guarantee that the invoking terminal is available as Console.In to every task, logger, resolver, worker, TaskHost, or server process.

This changes the recommended disposition of finding 5:

• Keep the proven protocol fact: interactive builds are server-eligible and MSBuild Server has no client-stdin packet.
• Downgrade it from a high supported-feature defect to a medium compatibility/documentation risk.
• Do not disable MSBuild Server whenever /interactive or NuGetInteractive is set.
• Do not build a raw stdin proxy solely for the examples found; the complexity is disproportionate and the task pattern is already considered unsafe.
• Document the contract and add characterization/no-hang coverage.

Confirmed production examples

1. MSBuild Community Tasks Prompt

Source:

• Prompt.cs
• Prompt.Execute() calling Console.ReadLine()

This is a real Microsoft.Build.Utilities.Task. Its documentation explicitly says:

• it requires console input;
• it should not be used unattended;
• it can be conditioned on $(Interactive);
• a primary example is pausing so a debugger can attach to msbuild.exe.

The containing MSBuildTasks NuGet package currently reports 9,866,848 total downloads:
https://azuresearch-usnc.nuget.org/query?q=packageid:MSBuildTasks

That download count measures the whole package, not use of this particular task. Prompt appears to be a fringe helper inside a historically popular task collection, but it establishes that the behavior shipped to a large user base.

2. BizTalk Deployment Framework Pause

Source:

• Pause : Task
• Execute() and Console.ReadKey(true)

This is another real in-task read. ReadKey is especially brittle because it can throw when no usable console/input stream exists rather than merely returning EOF.

BTDF is specialized enterprise tooling, so repository stars are not a reliable adoption proxy, but this is production BizTalk deployment infrastructure rather than a synthetic test.

3. Legacy Azure SDK build DebugTask

Public mirror of the legacy Azure SDK source:

• DebugTask : Microsoft.Build.Utilities.Task
• Task.Run, Console.ReadLine, and bounded wait`

The task wraps Console.ReadLine() in a timed task. That is useful historical evidence that task authors already expected direct input reads to hang in some hosts.

This is legacy/debug-only infrastructure, not a normal Azure SDK build dependency.

4. RoslynCodeTaskFactory inline Pause

Source:

• UsingTask TaskName="Pause"
• Task invocations

The inline task executes:

System.Console.WriteLine("Press ENTER to continue ...");
System.Console.ReadLine();

This has very low reach and is explicitly debugging-oriented, but it demonstrates that the pattern is also reachable through inline task factories.

What was not found

• No production ILogger or IForwardingLogger implementation reading stdin was confirmed.
• No widely used modern task was found where stdin is essential to its normal build function.
• Most search hits were console applications that happen to host MSBuild, child tools launched by tasks, tests/samples, or standalone Main methods. Those do not establish an MSBuild task contract.
• No confirmed report was found where MSBuild documented arbitrary task Console.ReadLine/ReadKey as supported across nodes/hosts and MSBuild Server later regressed that guarantee.

The observed production pattern is narrowly:

Prompt / pause / attach debugger / manually confirm a build step

Current MSBuild guidance already treats this as unsafe

The task analyzer in the audited MSBuild revision treats every Console.* member in an ITask implementation as an error:

• TaskAnalyzer/README.md
• MultiThreadableTaskAnalyzer.cs

The guidance explicitly says:

• Console.* interferes with build logging;
• Console.ReadLine / Console.Read may deadlock automated builds;
• these APIs are never safe in an MSBuild task implementation.

That makes direct task stdin better viewed as an existing portability anti-pattern exposed by persistence/multi-node execution, rather than a supported /interactive feature requiring transparent server emulation.

What /interactive is used for in supported scenarios

The public wording is broad ("build actions are allowed to interact"), but implementation primarily propagates a Boolean policy:

• BuildParameters.Interactive
• reserved MSBuildInteractive
• SDK resolver Interactive
• legacy NuGetInteractive compatibility

The switch does not create or route a terminal stream.

Historical introduction:
dotnet#3697

Official references:

• https://learn.microsoft.com/visualstudio/msbuild/msbuild-command-line-reference#switches
• https://learn.microsoft.com/dotnet/api/microsoft.build.execution.buildparameters.interactive
• https://learn.microsoft.com/dotnet/api/microsoft.build.framework.sdkresolvercontext.interactive

The .NET SDK's --interactive commonly forwards NuGetInteractive=true; it is not necessarily the MSBuild /interactive switch.

NuGet authentication does not require MSBuild client stdin

The supported MSBuild restore path passes interaction policy into credential-provider infrastructure:

• BuildTasksUtility.SetupDefaultCredentialService
• CredentialService
• GetAuthenticationCredentialsRequest

V2 credential providers run as child processes and exchange machine-readable protocol messages over redirected pipes:

• PluginFactory
• https://learn.microsoft.com/nuget/reference/extensibility/nuget-cross-platform-plugins

Human action normally happens through:

• browser/broker/dialog authentication;
• device code plus a visible URL/code;
• Visual Studio host callbacks;
• external completion while the provider waits.

Representative Azure Artifacts provider implementations:

• MsalInteractiveTokenProvider
• MsalDeviceCodeTokenProvider

No MSBuild client keystroke transport is needed for these flows.

This exact server decision was already made

dotnet/msbuild#12225 tracked that interactive mode disabled MSBuild Server after the SDK made interaction default on interactive consoles.

The resolution was explicit:

NuGet auth doesn't need direct access to stdin, and as of the recent TerminalLogger changes the credential provider messages are always shown to users.

dotnet#12225 (comment)

The interactive exclusion was removed in:
dotnet#12321

Disabling the server again for every interactive SDK build would undo that decision and, because modern SDK commands default to interactive outside CI/redirection, would disable server use for much of the intended local-build population.

Known interactive failures were generally not stdin failures

Representative incidents:

• dotnet/msbuild#4036: /interactive failed to propagate NuGet interaction policy.
• dotnet/msbuild#8523: static-graph evaluation failed to propagate interaction to SDK resolvers.
• dotnet/sdk#27597: interactive restore failed with the earlier server implementation; later investigation pointed at reused NuGet/process state.
• NuGet/Home#12540: timed-out device-flow state was cached in a reused process.
• dotnet/msbuild#9068: Terminal Logger hid device-flow instructions until timeout.
• dotnet/msbuild#12225: concluded NuGet interaction did not need stdin and removed the server exclusion.

These are mostly policy propagation, output visibility, credential-provider selection, and reused static/plugin-state problems. They do not demonstrate a supported need for task Console.In.

What the no-stdin server protocol actually threatens

Threatened

• Custom tasks, loggers, or SDK resolvers directly calling Console.Read* while running in the server entry process.
• Code depending on raw key input, echo suppression, or current-terminal properties.
• A child process that expects to inherit the invoking client's current terminal.
• Piped data intended for top-level MSBuild consumption.

Even if a cold server happened to inherit the first launcher's input handle, a reused server could not associate that handle with later clients.

Not threatened

• NuGet V2 plugin JSON communication.
• Browser, broker, or dialog authentication.
• Device-code authentication that prints a URL/code and waits for out-of-band completion.
• Visual Studio credential callbacks and task host objects.
• Static-graph restore's own purpose-created child stdin pipe.
• Token/cache/environment-based noninteractive authentication.

This is largely an existing cross-node limitation

Arbitrary task stdin was already unreliable outside the classic single-process entry node:

• worker/task-host launch does not expose the invoking terminal as a portable input contract:
  NodeLauncher.cs,
  #L264-L278;
• ToolTask closes redirected child stdin to avoid tools blocking for input:
  ToolTask.cs,
  #L803-L811.

The new risk is specifically code that happened to remain on the classic CLI entry process and relied on its inherited terminal.

Recommended issue disposition

Change finding 5 from:

High: interactive builds are server-eligible, but the protocol has no stdin.

to:

Medium: /interactive does not define a portable task-stdin contract.

MSBuild Server has no client-stdin transport, so legacy/custom tasks that directly use Console.Read* can fail, return EOF, or hang when they execute in the server entry process. Real examples exist, but the pattern is niche, was already unreliable across worker/task-host/IDE/CI hosts, and is explicitly rejected by the MSBuild task analyzer. Supported NuGet interaction uses policy propagation plus credential-provider/browser/device-code mechanisms and does not require MSBuild stdin.

Recommended actions

1. Keep interactive builds server-eligible.

2. Document the contract, for example:

   Interactive is a request-scoped authorization signal. Components may block for a browser, dialog, device-code completion, or host callback, but MSBuild does not guarantee that the invoking client's terminal is available as Console.In to tasks, loggers, SDK resolvers, worker nodes, task hosts, or server processes.

3. Add characterization tests for Console.ReadLine, ReadKey, and Console.IsInputRedirected under:

   • classic single-process MSBuild;
   • MSBuild Server;
   • /m worker node;
   • TaskHost;
   • Visual Studio;
   • redirected/piped input.

4. Tests should guarantee no indefinite hang and produce a clear diagnostic; they should not imply stdin support in every host.

5. Add an end-to-end server test for a real V2 credential provider/device-code flow, including reused interactive -> noninteractive -> interactive requests and immediate message visibility.

6. Continue using the task analyzer to reject direct Console.* usage in task implementations.

7. If arbitrary client input is ever desired, design an explicit interaction service/capability rather than treating raw stdin as an implicit consequence of /interactive.

An input protocol would need to define:

• which task owns the reader;
• concurrent-build arbitration;
• cancellation and EOF;
• encoding and redirected input;
• secret/no-echo handling;
• ReadKey/TTY behavior;
• worker-node routing or entry-node affinity;
• prevention of a reused server reading from the wrong client.

That is a substantial feature and is not justified solely by the small number of legacy prompt/pause tasks found.