Problem
Currently, the VS Code extension always assumes the CLI binary name follows the download artifact naming convention (coder-<os>-<arch> with the appropriate extension). When a user has the Coder CLI pre-installed via a package manager (e.g., winget on Windows, homebrew, apt, etc.), the installed binary is typically just named coder (or coder.exe on Windows), not coder-windows-amd64.exe.
This means users who have downloads disabled and want to point the extension at a pre-installed CLI cannot do so easily — they would need to create a symlink with the expected artifact name.
This is the same issue reported for the JetBrains plugin in coder/jetbrains-coder#598 and being addressed for the Toolbox plugin as well.
Proposed Solution
Allow the binary directory setting to accept either:
- A full path to the binary (e.g.,
/usr/bin/coder or C:\Program Files\Coder\coder.exe) — if the path points to an executable file, use it directly.
- A directory path (current behavior) — look for
coder and coder-<os>-<arch> (appending .exe on Windows) within the directory.
When downloads are disabled:
- If the configured path is directly to an executable file, use it as-is with no fallback.
- If it is a directory, check for
coder (or coder.exe) first, then fall back to coder-<os>-<arch> naming, then fall back to the data directory with the default binary name.
Context
Discussion in the team concluded that this approach is both backward-compatible (existing directory-based configs continue to work) and addresses the user need to point at a pre-installed CLI with a different name than the release artifact.
Created on behalf of @EhabY
Problem
Currently, the VS Code extension always assumes the CLI binary name follows the download artifact naming convention (
coder-<os>-<arch>with the appropriate extension). When a user has the Coder CLI pre-installed via a package manager (e.g., winget on Windows, homebrew, apt, etc.), the installed binary is typically just namedcoder(orcoder.exeon Windows), notcoder-windows-amd64.exe.This means users who have downloads disabled and want to point the extension at a pre-installed CLI cannot do so easily — they would need to create a symlink with the expected artifact name.
This is the same issue reported for the JetBrains plugin in coder/jetbrains-coder#598 and being addressed for the Toolbox plugin as well.
Proposed Solution
Allow the binary directory setting to accept either:
/usr/bin/coderorC:\Program Files\Coder\coder.exe) — if the path points to an executable file, use it directly.coderandcoder-<os>-<arch>(appending.exeon Windows) within the directory.When downloads are disabled:
coder(orcoder.exe) first, then fall back tocoder-<os>-<arch>naming, then fall back to the data directory with the default binary name.Context
Discussion in the team concluded that this approach is both backward-compatible (existing directory-based configs continue to work) and addresses the user need to point at a pre-installed CLI with a different name than the release artifact.
Created on behalf of @EhabY