fix(python): select the current platform's CLI package in the E2E harness

[nytron88]

Fixes #2103.

The Python E2E harness resolved the Copilot CLI by taking the first
@github/copilot-* directory in alphabetical order, so a tree with more than one
platform package could launch an entrypoint built for another OS/arch — whichever
name sorted first won, regardless of the host. The glob could also match
non-platform packages such as copilot-language-server.

It now probes the exact platform package names for the host — reusing
copilot._cli_version.get_npm_platform(), which already owns the platform, arch and
musl-vs-glibc mapping — mirroring getCliPlatformPackageNames() in
nodejs/src/client.ts and the .NET fix in #2093. On Linux both libc variants are
tried, detected one first. When nothing matches, the error names the directory
searched, the packages tried, the packages actually present, and COPILOT_CLI_PATH.

New unit tests in python/test_e2e_harness_cli_path.py cover this against fixture
directory trees under tmp_path, so no real CLI is ever launched.

Behaviour change on mixed-architecture hosts

platform.machine() reflects the Python interpreter, but the resolved index.js is
executed by node (python/copilot/client.py:3900-3901 prepends node for .js
paths), and which platform package exists on disk was decided by whichever npm ran the
install. On a host where those differ — x86_64 CPython under Rosetta alongside native
arm64 node — the old loose glob happened to find copilot-darwin-arm64 and work, and
this change fails fast instead.

That is deliberate: silently launching a package built for a different architecture is
the bug being fixed. COPILOT_CLI_PATH keeps top precedence as the escape hatch and is
named in the error, which also lists the packages actually present so the mismatch is
visible rather than mysterious.

Worth naming the divergence from #2093: it keys on the OS prefix only and globs -* for
the arch, so it does not pin the architecture — this is the stricter of the two. Both
fail fast on the ordering bug itself (.NET errors on an ambiguous multi-package tree), so
the difference is narrowly about an arch mismatch on a single-package tree.

Note: go/internal/e2e/testharness/context.go:36-41 has the identical bug — filed
separately as #2116 to keep this PR scoped to the issue.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[syedkazmi14]

@nytron88 Thanks, this is really helpful.

Reusing copilot._cli_version.get_npm_platform() sounds like the right approach to me. I’d prefer to keep this fix scoped to the platform-aware package selection bug itself, so I would leave the lazy CLI_PATH resolution change out of this PR and track that separately if it still seems worth doing after this lands.

The mixed-architecture fail-fast behavior also seems like the right trade-off here to me. If the current interpreter arch does not match the installed CLI package, surfacing that clearly is better than silently picking a different package, and COPILOT_CLI_PATH seems like a reasonable escape hatch for unusual setups.

Also appreciate you filing the Go version separately.

[nytron88]

Thanks @syedkazmi14 — done, and agreed on both counts.

Dropped the lazy CLI_PATH change. Force-pushed; the branch is four commits now:

818249f2 fix(python): name the installed CLI packages when resolution fails
5a7105a0 fix(python): select the current platform's CLI package in E2E harness
469847bd test(python): probe exact CLI platform package names on disk
e164fb24 test(python): resolve E2E CLI candidates by host platform

The last one stays because it is part of the selection fix rather than the hardening: when
nothing matches, the error now lists the copilot-* packages actually present alongside the
ones tried. That matters specifically for the mixed-arch case below — otherwise the message
tells you to run npm install while the package npm would install is already sitting in that
directory, which is a dead end with no way to see why.

One consequence worth stating plainly, since it is the reason I had bundled the change: with
that commit out, CLI_PATH = get_cli_path_for_tests() runs at module scope again, so on a host
that cannot resolve a matching package the new unit tests fail at collection rather than as
test failures — even though they only use tmp_path fixtures and need no CLI. CI is unaffected
(npm ci --ignore-scripts runs in nodejs/ before pytest), so this only shows up on a fresh
clone or a stale worktree locally. Happy to leave it exactly as you suggested; I have parked the
work on spike/lazy-cli-path-2103
and will open an issue after this lands if it still looks worth doing.

On the mixed-architecture trade-off — that matches my read too, so I have reworded that part
of the PR description from an open question into a plain note about the behaviour change, and
kept the detail that the divergence from #2093 is intentional (that one keys on the OS prefix
only and does not pin the arch, so this is the stricter of the two).

Current state on this branch: 17 tests in python/test_e2e_harness_cli_path.py, 302 in the flat
unit suite, e2e/test_client_e2e.py 14/14 against the real CLI, ruff format --check and
ruff check clean on each commit individually.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.