Harden Extension E2E Tests With --yolo For Permission Gate Compatibility

[MRayermannMSFT]

What

Adds --yolo CLI flag to all extension-related E2E tests across all four SDKs (Node, Python, Go, .NET). This ensures that if extensions ever require user approval before loading then these tests will auto-approve and continue to pass without modification. Tests that specifically validate extension permission behavior are left unchanged.

Why

The Copilot CLI's extension system is evolving, and new permission gates may be introduced that prompt users before loading extensions. Without this hardening, any extension E2E test that doesn't explicitly handle such a gate would start failing. By passing --yolo at the CLI level as defense-in-depth (on top of the existing approveAll session handler), these tests are resilient to future permission-related changes in the runtime without masking intentional permission-testing scenarios.

[Copilot]

Pull request overview

This PR hardens extension-related E2E tests across the Node, Python, Go, and .NET SDKs by passing --yolo to the spawned Copilot CLI process. This ensures tests continue to run unattended if future Copilot CLI/runtime changes introduce additional interactive permission gates for extensions, while continuing to rely on per-session permission handlers where appropriate.

Changes:

• Python E2E harness now supports optional extra CLI arguments when spawning the CLI subprocess.
• Extension-related E2E tests in Node/Python/Go/.NET pass --yolo via their client/fixture setup.
• .NET extension-loaded E2Es factor client creation into a helper to consistently apply --yolo + EXTENSIONS feature-flag environment.

Show a summary per file

File	Description
python/e2e/testharness/context.py	Adds optional cli_args plumbing to pass additional CLI args into the spawned subprocess config.
python/e2e/test_rpc_mcp_and_skills_e2e.py	Overrides the module ctx fixture to spawn the CLI with --yolo for this extension-related E2E module.
nodejs/test/e2e/rpc_mcp_and_skills.e2e.test.ts	Passes cliArgs: ["--yolo"] into the Node E2E harness client options.
go/internal/e2e/rpc_mcp_and_skills_e2e_test.go	Passes --yolo via ClientOptions.CLIArgs when creating the Go E2E client.
dotnet/test/E2E/RpcMcpAndSkillsE2ETests.cs	Uses a per-test --yolo client for extension RPC tests to avoid future permission-gate breakage.
dotnet/test/E2E/RpcExtensionsLoadedE2ETests.cs	Introduces a helper to create an extensions-enabled client that also includes --yolo, then uses it throughout the file.

Copilot's findings

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

[github-actions]

Cross-SDK Consistency Review ✅

This PR consistently applies the --yolo hardening across all four SDK implementations in a single change — no cross-SDK gaps detected.

Summary by SDK

SDK	Approach	Scope
Node.js	cliArgs: ["--yolo"] passed to createSdkTestContext()	Whole test module
Python	New ctx fixture overrides module default with cli_args=["--yolo"]; context.setup() extended to accept cli_args	Whole test module
Go	o.CLIArgs = []string{"--yolo"} on the shared test function client	Whole test function
.NET	New CreateExtensionsClient() helper (extensions-only class) + inline yoloClient per test (mixed-purpose class)	Per-test where needed

Naming & API alignment

The --yolo flag plumbs through the same underlying ClientOptions.cliArgs/CLIArgs/CliArgs/cli_args field in each SDK — consistent with the cross-language naming convention (camelCase → snake_case → PascalCase).

Minor observation (non-blocking)

In RpcMcpAndSkillsE2ETests.cs, two tests each inline a yoloClient independently rather than extracting a shared helper. This contrasts with RpcExtensionsLoadedE2ETests.cs's CreateExtensionsClient() pattern — but it's appropriate here since only those two tests in a larger class need the flag. Not a consistency issue.

No action needed in other SDKs. 🎉

Generated by SDK Consistency Review Agent for issue #1204 · ● 157.4K · ◷