Summary

azd waza run (v0.12.0) fails immediately on Windows with [ERROR] copilot failed to start: CLI process exited: exit status 1 — same symptom as #42, but in a new failure mode. The embedded Copilot CLI (v1.0.49) appears to never get extracted, and the SDK falls through to PATH lookup where it finds an incompatible copilot binary.

Environment

• OS: Windows 11 Enterprise 10.0.26200
• azd: 1.20.1
• waza extension: microsoft.azd.waza 0.12.0
• Shell: PowerShell 7 (running inside a VS Code terminal that has its own Copilot CLI session active)
• PATH contains, in order:
  1. C:\Users\<user>\AppData\Local\Microsoft\WinGet\Links\copilot.exe — this is Microsoft 365 Copilot (a GUI app), not GitHub Copilot CLI; it hangs on any CLI invocation
  2. Q:\.tools\.npm-global\copilot.cmd / copilot.ps1 — npm-installed @github/copilot v0.0.358
• copilot --version → 0.0.358 / Commit: f5a8b1e76
• copilot --headless → error: unknown option '--headless' (exit 1)

Repro

1. git clone https://github.com/microsoft/waza && cd waza
2. azd waza run examples/code-explainer/eval.yaml (with executor: copilot-sdk)
3. Every task fails with copilot failed to start: CLI process exited: exit status 1 in ~900 ms.

Diagnosis

The embedded CLI (v1.0.49) bundled into the waza binary is never extracted on my machine.

Evidence:

• After multiple runs, %LOCALAPPDATA%\copilot-sdk\ does not exist.
• %USERPROFILE%\.copilot\cache\copilot-sdk\ does not exist (also tried setting COPILOT_HOME).
• Setting COPILOT_CLI_INSTALL_VERBOSE=1 produces no extra output — neither the success line nor the error line. So either embeddedcli.Path() is never called, or the verbose env var isn''t surfacing through the azd→extension subprocess chain, or install() is exiting before the deferred print.

When embeddedcli.Path() returns "", copilot-sdk falls through to exec.Command("copilot", ...) and finds the npm-installed copilot v0.0.358 — which lacks --headless and exits 1 immediately, exactly matching the observed failure.

This is the same failure category as #42; the bundled-CLI fix unblocked the original reporter but doesn''t help when extraction silently no-ops.

What would help

1. Don''t fail silently — when embeddedcli.Path() returns "", log a warning at INFO level with the reason (not gated on COPILOT_CLI_INSTALL_VERBOSE). Today the only signal is the downstream "exit status 1" with no hint that the embedded path was abandoned.
2. Log which CLI is being used — print the resolved cliPath (embedded vs PATH lookup) at startup so users can see when it falls through.
3. Detect incompatible PATH copilot — before spawning, run copilot --version (or --help) and refuse to use it if --headless isn''t supported. Better error than a generic exit-1.
4. Optional: expose a --cli-path flag / COPILOT_CLI_PATH env to force a specific binary.

I''m happy to gather more diagnostics (e.g., adding temporary debug logging and rebuilding from source). I can also send a PR for (1) and (2) if you''d like — they look localized to internal/execution/copilot.go and internal/embedded.

Workaround attempts that did NOT help

• Removing the WinGet directory from PATH (still falls through to npm copilot.cmd, still exits 1).
• Clearing COPILOT_AGENT_SESSION_ID, COPILOT_CLI, COPILOT_OTEL_* env vars.
• Setting COPILOT_HOME=%USERPROFILE%\.copilot to redirect install dir.
• Switching executor to mock — main task runs mock but prompt graders still call the SDK and hit the same error.

Related: #42 (closed via bundling).