ProtectedconfiguredProtected ReadonlyloggerProtectedresolutionProtectedbundledThe executable of a platform package that was installed alongside this application, if any.
Both the module paths of this file and those of the Copilot SDK are searched, so that the package is found whether the installation hoisted it or nested it below the SDK.
ProtecteddoProtectedenvironmentThe location given in the environment, resolved the same way as a configured one.
The variable is documented as doing what the preference does, so a directory or a launcher is accepted here as well. A value that leads nowhere is reported and then left behind rather than turned into an error, so that the remaining sources still get their chance.
ProtectedgetProtectedgetThe names a CLI can go by in a directory that is on the PATH or that a user configured: the
executable itself, and on Windows in addition the shim a global npm installation writes, since
that is the only entry it puts there.
ProtectedgetThe platform-specific packages that can carry the CLI for this host. On Linux both the glibc and the musl build are candidates.
ProtectedglobalThe executable of a globally installed CLI, for the case that the global binary directory is
not on the PATH of the backend process. That is common when the application was started from
a desktop launcher rather than from a shell.
ProtectedisProtectedisProtectedisWhether the given path is something that starts the CLI rather than the CLI itself, which is either its JavaScript entry point or a shim of a global installation.
ProtectedisProtectedmoduleThe executables a module directory can hold the CLI in.
A global installation nests the platform package below the launcher rather than hoisting it, so the launcher is used to resolve from, and the hoisted layout is tried as well.
ProtectedpathThe executable of a CLI that is on the PATH of the backend process.
A global npm installation does not put the executable itself there but a launcher: a link to
the JavaScript entry point on Linux and macOS, and a .cmd shim on Windows. Such a hit is
therefore mapped to the platform package it belongs to, see toCandidatesOnPath.
Resolves the executable of the Copilot CLI, and remembers it for later calls. Rejects with an explanation of where it was searched when there is none.
ProtectedresolveAccepts the configured location either as the executable itself or as the directory holding it,
so that both what a user has on their PATH and what a package manager installed can be given.
A configured launcher is followed to the executable it would start, because that is what which
or whereis report for a global installation. Starting the launcher would work as well, but only
for as long as a Node.js is on the PATH of the backend, which is nothing to rely on.
ProtectedresolvedThe executable of a platform package as Node.js resolves it from the given file.
This is how the launcher of the CLI finds its own executable, and it is the only lookup that covers every layout: an installation hoists the platform package next to the launcher, while a global installation nests it below the launcher instead. The package points its main entry at the executable, so the directory of what was resolved is the directory holding it.
Sets the location the user configured, which takes precedence over every other source. A changed value discards what was resolved before.
ProtectedtoInterprets what a copilot on the PATH points at: a launcher of a global npm installation is
mapped to the executable of the platform package it would start, anything else is taken to be
the executable itself.
ProtectedtoThe executables the platform packages of this host would have below the given module directory.
Locates the executable of the GitHub Copilot CLI on the machine running the backend.
The CLI is a native executable that GitHub ships in a platform-specific package. It is looked up rather than bundled, because it is a large proprietary binary that an application does not necessarily carry: a packaged application (for example an AppImage) cannot execute a binary from inside its archive, and an installation may deliberately not ship it at all. Users install the CLI themselves, the same way as for the Claude Code integration.
The native executable is resolved rather than the
index.jsentry point of the same package, so that it can be spawned directly. Spawning the JavaScript entry point would require a Node.js executable, which the backend does not have at hand:process.execPathis the Electron binary in an Electron application, and starting that would start a second application instead of the CLI.