Skip to content

fix(copilot): detect copilot.exe on Windows instead of assuming copilot.cmd - #4758

Open
chelsealong wants to merge 1 commit into
github:mainfrom
chelsealong:fix/4755-copilot-windows-executable-detection
Open

chelsealong wants to merge 1 commit into
github:mainfrom
chelsealong:fix/4755-copilot-windows-executable-detection

Conversation

@chelsealong

Copy link
Copy Markdown
Contributor

Fixes #4755

Problem

_copilot_executable() in src/specify_cli/integrations/copilot/__init__.py
hardcoded copilot.cmd as the Windows executable name, assuming the GitHub
Copilot CLI was always installed via an npm global install (which wraps the
binary in a .cmd shim on Windows). Any other install channel — a standalone
installer, winget, scoop, or a signed native binary — puts copilot.exe
on PATH instead. Because Spec Kit never probed PATH, workflow/command-step
dispatch to the copilot integration failed outright for those installs on
Windows (copilot.cmd not found), even though a working Copilot CLI was
present.

Fix

_copilot_executable() now probes PATH on Windows with shutil.which,
preferring copilot.exe, then copilot.cmd, then falls back to the
historical copilot.cmd default if nothing is found (so the resulting
"command not found" error still references the previously expected name).
Non-Windows behavior ("copilot") is unchanged. The env-var override
(SPECKIT_INTEGRATION_COPILOT_EXECUTABLE) still takes precedence, unchanged.

This mirrors the fix suggested in the issue report.

Test evidence

Added three regression tests in tests/integrations/test_extra_args.py
that monkeypatch os.name and shutil.which to simulate the three Windows
scenarios: only copilot.exe present, only copilot.cmd present, and
neither present.

Confirmed the key regression test fails without the fix
(git checkout HEAD~1 -- src/specify_cli/integrations/copilot/__init__.py,
then restored):

FAILED tests/integrations/test_extra_args.py::test_copilot_executable_windows_prefers_exe_on_path
AssertionError: assert 'copilot.cmd' == 'copilot.exe'

With the fix, all three new tests plus the existing Copilot executable/extra-args
tests pass:

$ .venv/bin/python -m pytest tests/integrations/test_extra_args.py -v -k copilot
...
8 passed, 30 deselected in 0.11s

Full suite (.venv/bin/python -m pytest): 10 failed, 8582 passed, 13 skipped.
The 10 failures are pre-existing *_python_parity tests (bash/PowerShell vs.
Python template-composition parity) unrelated to this change — confirmed by
running the same test files against the unmodified main branch, which
produces the identical 10 failures.

AI disclosure

Implemented autonomously by an OSS-contribution agent running Claude Code
(Claude Sonnet 5, claude-sonnet-5), operating without human line-by-line
review before this push. Extent: full code change and test authored by the
agent, based on the fix already suggested in the issue body; issue
investigation, prior-PR/claim search, and test verification (including the
before/after regression check) were also performed by the agent.

🤖 Generated with Claude Code

…ot.cmd

_copilot_executable() hardcoded the npm-shim name copilot.cmd on
Windows, so workflow command-step dispatch failed for any Copilot CLI
install that puts copilot.exe on PATH instead (standalone installer,
winget, scoop). Probe PATH for copilot.exe, then copilot.cmd, before
falling back to the historical default.

Fixes github#4755

Assisted-by: Claude Code (model: Claude Sonnet 5, autonomous)
@chelsealong
chelsealong requested a review from mnriem as a code owner September 25, 2026 17:36

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Windows: Copilot integration hardcodes copilot.cmd, breaking installs that ship copilot.exe

1 participant