Avoid shell kill cwd cleanup flakes

[stephentoub]

The Windows .NET E2E failure was caused by a long-running shell-kill test command inheriting the disposable fixture workspace as its current directory. If the shell wrapper was killed but a child process briefly survived, Windows could keep copilot-test-work-* locked and fail cleanup.

This updates the shell-kill E2E tests across .NET, Node, Go, and Python to run the long-lived command from the system temp directory instead of the fixture workspace. The tests still exercise session.shell.kill, but a surviving child process can no longer block deletion of the per-test workspace.

Validation:

• dotnet test dotnet\test\GitHub.Copilot.SDK.Test.csproj --filter FullyQualifiedName~RpcShellAndFleetE2ETests.Should_Kill_Shell_Process -v n
• cd nodejs && npm test -- --run test/e2e/rpc_shell_and_fleet.e2e.test.ts -t "should kill shell process"
• cd go && go test ./internal/e2e -run TestRpcShellAndFleetE2E/should_kill_shell_process -count=1
• python -m pytest python\e2e\test_rpc_shell_and_fleet_e2e.py::TestRpcShellAndFleet::test_should_kill_shell_process
• cd nodejs && npm exec prettier -- --check test/e2e/rpc_shell_and_fleet.e2e.test.ts
• python -m ruff format python\e2e\test_rpc_shell_and_fleet_e2e.py --check

[Copilot]

Pull request overview

This PR hardens the cross-SDK session.shell.kill E2E coverage by preventing long-lived shell commands from running inside disposable per-test workspaces. That fits the repo’s shared goal of keeping language SDK tests aligned while avoiding platform-specific flakiness in the common shell RPC surface.

Changes:

• Updated the .NET, Node, Go, and Python shell-kill E2E tests to run the long-lived command from the system temp directory.
• Preserved the existing session.shell.kill behavior under test while avoiding Windows cleanup failures caused by lingering cwd handles.
• Added clarifying comments in each test explaining the Windows-specific cleanup rationale.

Show a summary per file

File	Description
python/e2e/test_rpc_shell_and_fleet_e2e.py	Uses tempfile.gettempdir() for the shell-kill test command cwd.
nodejs/test/e2e/rpc_shell_and_fleet.e2e.test.ts	Uses os.tmpdir() for the shell-kill test command cwd.
go/internal/e2e/rpc_shell_and_fleet_e2e_test.go	Uses os.TempDir() for the shell-kill test command cwd.
dotnet/test/E2E/RpcShellAndFleetE2ETests.cs	Uses Path.GetTempPath() for the shell-kill test command cwd.

Copilot's findings

• Files reviewed: 4/4 changed files
• Comments generated: 0

[github-actions]

Cross-SDK Consistency Review ✅

This PR makes two types of changes and both are handled consistently across all four SDKs.

1. E2E Test Fix (all 4 SDKs — consistent ✅)

The shell-kill test fix (cwd: tempdir) is applied uniformly across all four SDKs:

SDK	File	Change
.NET	dotnet/test/E2E/RpcShellAndFleetE2ETests.cs	cwd: Path.GetTempPath()
Go	go/internal/e2e/rpc_shell_and_fleet_e2e_test.go	Cwd: &cwd (os.TempDir())
Node.js	nodejs/test/e2e/rpc_shell_and_fleet.e2e.test.ts	cwd: os.tmpdir()
Python	python/e2e/test_rpc_shell_and_fleet_e2e.py	cwd=tempfile.gettempdir()

2. .NET Client Stderr Race Fix (internal implementation — no cross-SDK gap ✅)

The dotnet/src/Client.cs change improves stderr capture when a ConnectionLostException occurs by waiting up to 250 ms for the stderr reader task to flush. This is an internal implementation detail, and the other SDKs already have equivalent mechanisms:

• Node.js — uses a 50 ms setTimeout delay in processExitPromise (raced against RPC calls) before reading stderrBuffer
• Python — has a background _stderr_thread that continuously reads stderr into _stderr_output; the loop already handles the read-after-exit case
• Go — does not capture stderr in its client at all (uses a different error signaling model via a processDone channel), so this fix has no counterpart to add

The .NET change brings its stderr-race behavior in line with what Node.js already does via the setTimeout approach — both now give the subprocess a brief window to fully flush stderr before the error message is composed. No equivalent changes are needed in the other SDKs.

No consistency issues identified. 🎉

Generated by SDK Consistency Review Agent for issue #1207 · ● 669K · ◷