Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#4,755 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
88/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
cli, testing-qa

Rechercherichtung

Beginne in src/specify_cli/integrations/copilot/init.py mit dem Lesen von _copilot_executable() und _resolve_executable(), und führe anschließend die bestehende Coverage in tests/integrations/test_extra_args.py aus. Füge eine Regressionstestabdeckung für einen Windows PATH hinzu, der nur copilot.exe enthält, und betrachte das Issue als erledigt, wenn der Befehlsversand eine installierte ausführbare Datei auflöst, statt copilot.cmd vorauszusetzen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug-assess severity-medium triage-nice-to-have
Bug Description

CopilotIntegration._resolve_executable() falls back to a hardcoded, platform-guessed executable name on Windows (copilot.cmd) instead of detecting what's actually installed. When the GitHub Copilot CLI is installed in a way that produces copilot.exe rather than an npm-style .cmd shim, workflow/command dispatch to the copilot integration fails outright on Windows, because Spec Kit never looks for the actual executable on PATH.

Steps to Reproduce
  1. On Windows, install the Copilot CLI via a distribution that produces copilot.exe on PATH (not an npm global-install shim producing copilot.cmd).
  2. Run any Spec Kit workflow/command step with integration: copilot (e.g. specify workflow run ...).
  3. Dispatch fails because Specify attempts to invoke copilot.cmd, which does not exist, instead of the copilot.exe that is actually on PATH.
Expected Behavior

Spec Kit should detect the actual Copilot CLI executable available on the user's PATH on Windows, rather than assuming a single fixed name.

Actual Behavior

Specify attempts to invoke copilot.cmd even when only copilot.exe is installed on PATH, so workflow/command dispatch fails.

Specify CLI Version

1.0.7 (as encountered; likely affects other versions using the same _copilot_executable() logic)

AI Agent

GitHub Copilot

Operating System

Windows (version not specified)

Python Version

N/A (not provided)

Error Logs

N/A (no specific error output provided)

Additional Context

Where: src/specify_cli/integrations/copilot/__init__.py

def _copilot_executable() -> str:
    """Return the executable name for Copilot CLI on this platform.

    On Windows, subprocess invocation is reliable with `copilot.cmd`.
    """
    if os.name == "nt":
        return "copilot.cmd"
    return "copilot"

def _resolve_executable(self) -> str:
    """Return the Copilot CLI executable, respecting the env-var override.

    Checks ``SPECKIT_INTEGRATION_COPILOT_EXECUTABLE`` first.  Falls
    back to the platform-specific default from ``_copilot_executable()``
    (``copilot.cmd`` on Windows, ``copilot`` elsewhere) so that
    existing behaviour is preserved when the env var is unset.
    """
    env_name = "SPECKIT_INTEGRATION_COPILOT_EXECUTABLE"
    override = os.environ.get(env_name, "").strip()
    return override if override else _copilot_executable()

Why this likely wasn't caught earlier:

  • Workflow command-step dispatch is a newer code path. Most integration scaffolding (init, command registration, writing .github//.claude/ files) never has to spawn the Copilot CLI as a subprocess. _resolve_executable()/build_exec_args() only matter once something actually shells out to copilot, which is essentially exclusive to specify workflow run command steps — so long-time Spec Kit + Copilot users could easily never exercise this path.
  • The hardcoded copilot.cmd guess suggests testing only covered an npm global install (npm install -g @github/copilot or similar), which npm wraps in a .cmd shim on Windows by convention. Installing the Copilot CLI via a different channel (standalone installer, winget, scoop, a signed native binary, etc.) produces a real copilot.exe on PATH instead, and hits this bug immediately and reliably. If most Windows testers install via npm, this simply never surfaces for them.
  • The SPECKIT_INTEGRATION_COPILOT_EXECUTABLE override itself appears recently added (per its own docstring: "so that existing behaviour is preserved when the env var is unset"), suggesting this is a known, actively-being-patched rough edge rather than a long-stable path.

Net: this only surfaces at the intersection of (a) workflows that dispatch to Copilot as a subprocess, (b) Windows, and (c) a non-npm Copilot CLI install — a narrow combination most contributors/testers may not sit in.

Suggested fix:

def _copilot_executable() -> str:
    """Return the executable name for Copilot CLI on this platform."""
    if os.name != "nt":
        return "copilot"

    for candidate in ("copilot.exe", "copilot.cmd", "copilot"):
        if shutil.which(candidate):
            return candidate

    # Nothing found on PATH — keep the historical default so the
    # resulting "command not found" error still references the
    # previously expected name.
    return "copilot.cmd"

shutil is already imported in this module, so this requires no new dependency. Suggest adding a regression test alongside the existing _resolve_executable/build_exec_args coverage in tests/integrations/test_extra_args.py, mocking shutil.which to simulate a Windows install exposing only copilot.exe.

Workaround: SPECKIT_INTEGRATION_COPILOT_EXECUTABLE already exists and can be set to copilot.exe explicitly, scoped to the invoking process, until this is fixed upstream.

AI Disclosure

GitHub Copilot (GPT-6 Sol) organized the user-provided issue text into the repository's bug-report template and filed it. Human-directed; no independent reproduction or code changes. Reasoning-effort setting not provided.

Vorherrschende Sprache
Python
Sterne
138k
Forks
12.4k
Ø Merge
2 T. 7 Std.
Gemergte PRs (30 T.)
158

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/spec-kit

Alle Issues in github/spec-kit

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.