Pin runner build SDK to 8.0.421 to mitigate macOS arm64 Process.Start deadlock in 2.336.0

[Copilot]

After the 2.336.0 update, macOS arm64 self-hosted runners can hang in Runner.Worker during Process.Start, with a forked child spinning pre-exec and jobs stalling indefinitely. This change targets the release-line regression surface by reverting the .NET SDK pin to the pre-regression version used before 2.336.0.

• Build/runtime pin rollback

  • Reverted SDK pin from 8.0.423 to 8.0.421 in all runner build entry points:
    • src/global.json
    • src/dev.sh
    • .devcontainer/devcontainer.json

• Scope

  • No worker/listener process-invocation logic changes.
  • No behavior changes outside SDK/runtime selection for builds.

// src/global.json
{
  "sdk": {
    "version": "8.0.421"
  }
}

• Fixes v2.336.0 on macOS (arm64): Runner.Worker deadlocks in Process.Start — forked child never execs, spins at 100% CPU; every job hangs seconds after start #4570

[TingluoHuang]

@copilot is there any bug in the dotnet SDK you can find that might cause the issue?

[Copilot]

@copilot is there any bug in the dotnet SDK you can find that might cause the issue?

I couldn’t find a .NET release note that explicitly says “8.0.422 introduces this exact hang,” but I did find strong upstream signals that this area is runtime-sensitive on macOS:

• Prefer posix_spawn on apple targets dotnet/runtime#126097 and the follow-up PR #126063 switched macOS process launch to prefer posix_spawn (instead of fork/exec paths), explicitly for Apple-target process reliability/perf concerns.
• There are prior macOS arm64 System.Diagnostics.Process bugs in the same surface area (e.g. Potential (~5% chance) AccessViolationException in ReadyToRun executable targeting RID osx.11.0-arm64/osx.12-arm64 when running a child process for the first time, and both standard output and standard error are redirected dotnet/runtime#88288 and #112167 around first child process start + redirected stdio).

So: no single confirmed 8.0.422 bug ID yet, but there is credible evidence this is a .NET runtime process-spawn issue on macOS rather than runner-specific logic.