Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#4,755 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
88/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python
Domaine
cli, testing-qa

Piste de recherche

Commencez dans src/specify_cli/integrations/copilot/init.py par lire _copilot_executable() et _resolve_executable(), puis exécutez la couverture existante dans tests/integrations/test_extra_args.py. Ajoutez une couverture de régression pour un PATH Windows ne contenant que copilot.exe, et considérez l’issue comme terminée lorsque la distribution des commandes résout un exécutable installé au lieu de supposer copilot.cmd.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
138k
Forks
12.4k
Merge moyen
2 j 7 h
PR mergées (30 j)
158

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de github/spec-kit

Toutes les issues de github/spec-kit

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.