Skip to content

Allow binaryDirectory setting to accept a full path to the CLI binary #861

@blinkagent

Description

@blinkagent

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:

  1. 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.
  2. 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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions