Install or upgrade the LATdx CLI on macOS, Linux, or Windows.

The LATdx CLI ships as platform-specific release bundles hosted on GitHub. Each bundle contains the latdx binary plus the Phase 4 reach-analysis JARs (jars/apex-ls.jar and jars/apex-ls-bridge.jar) so Phase 4 features work with no extra setup. There is no npm install -g. This page covers bundle install, release channels, and the in-place upgrade flow.

A Java 11+ runtime must be available on PATH for Phase 4 features. The bundle does not include a JRE.

Supported Platforms

Windows ARM64 is not published.

Bundle Layout

Every bundle extracts to:

latdx[.exe]              <- compiled CLI binary
jars/
  apex-ls.jar            <- Phase 4 reach-analysis engine (Apex-LS v6.x)
  apex-ls-bridge.jar     <- LATdx overlay (reach BFS, hash recipe)

The CLI auto-discovers the JARs via <execDir>/jars/, so the binary and jars/ directory must stay siblings on disk. Both install paths below preserve that layout.

Install (one-liner)

The install script downloads the right binary for your platform, drops it on your PATH, and runs latdx --help to verify.

curl -fsSL https://latdx.com/install.sh | bash

wget -qO- https://latdx.com/install.sh | bash

curl -fsSL https://latdx.com/install.sh | bash -s 1.2.3

curl -fsSL https://latdx.com/install.sh | bash

wget -qO- https://latdx.com/install.sh | bash

curl -fsSL https://latdx.com/install.sh | bash -s 1.2.3

Install (manual)

If you prefer not to pipe a remote script to bash, download the bundle for your platform from GitHub Releases  and extract it into a directory on your PATH, keeping the latdx binary and its sibling jars/ directory together.

INSTALL_DIR="$HOME/.local/bin"
mkdir -p "$INSTALL_DIR"
tar -xzf ./latdx-darwin-<arch>.tar.gz -C "$INSTALL_DIR"
latdx --help

INSTALL_DIR="$HOME/.local/bin"
mkdir -p "$INSTALL_DIR"
tar -xzf ./latdx-linux-<arch>.tar.gz -C "$INSTALL_DIR"
latdx --help

$InstallDir = "$env:USERPROFILE\bin"
New-Item -ItemType Directory -Force -Path $InstallDir | Out-Null
Expand-Archive -Force .\latdx-win-x64.zip -DestinationPath $InstallDir
# Add $InstallDir to PATH if it is not there
latdx --help

Release Channels

LATdx publishes two channels. Pick the one that matches your stability tolerance.

Channels are managed via latdx config:

latdx config get channel       # current channel (defaults to "stable")
latdx config set channel latest
latdx config list              # all configured keys

The channel value is persisted to ~/.latdx/config.json. It controls which release stream both latdx upgrade and the background update check compare against.

The install script honors the channel at install time too. An unpinned install resolves the newest build on the requested channel and, for latest, persists channel latest so upgrades keep tracking the same stream:

curl -fsSL https://latdx.com/install.sh | LATDX_CHANNEL=latest bash

On Windows, set $env:LATDX_CHANNEL = 'latest' before running the install.ps1 one-liner.

Upgrade

In-place upgrade to the newest release on the configured channel:

latdx upgrade

This re-runs the install script with the latest version pinned, so it requires curl or wget and write access to the install location.

Check without installing:

latdx upgrade check
latdx upgrade check --json     # { "currentVersion", "latestVersion", "updateAvailable" }

check --json is suitable for cron jobs or CI: a non-zero updateAvailable is a signal that a newer build exists on the channel.

Automatic Background Updates

By default the CLI installs newer versions for you. At most once an hour the CLI checks GitHub for a newer release on the configured channel (recording the result in ~/.latdx/update-check.json); when one is found the just-finished command exits normally and a detached child process downloads and installs the update in the background. The next CLI invocation runs the new version, and prints a one-line latdx updated to <version> breadcrumb to stderr exactly once.

• Continuous integration is always skipped (auto-detected via the CI env var). Pipelines never auto-update.
• Output of the just-finished command is never touched. Pipes and redirects work normally.
• A failed background install is logged to ~/.latdx/update.log and never surfaces to the user.
• Concurrent runs cooperate via ~/.latdx/update.lock; only one updater runs at a time.
• While a workspace daemon is running it also performs this check about once an hour, so an install that sits idle between commands still updates on its own. The same channel and opt-outs (autoUpdate=off, LATDX_AUTO_UPDATE, CI) apply, and it shares the same update.lock.

Opting out

Two equivalent ways to disable silent updates:

latdx config set autoUpdate off          # persisted to ~/.latdx/config.json
# or, ad-hoc:
LATDX_AUTO_UPDATE=0 latdx test run ...

When silent updates are off and a newer release is available, the CLI prints a one-line stderr notice instead so you still see release info:

Update available: 1.2.3 -> 1.2.4 (https://github.com/nebulity/latdx-cli/releases/latest)

LATDX_AUTO_UPDATE accepts 0, false, off, or no (case-insensitive) as opt-out values. Re-enable with latdx config set autoUpdate on.

Verifying the Install

latdx --version
latdx --version -o my-org      # also confirms the org is reachable

The org-augmented form returns a non-zero exit code if it cannot reach the org. Use it as a smoke test in CI before running tests.

Uninstall

The CLI is a single binary plus a sibling jars/ directory, with no installer database. Remove both, and optionally the per-user state directory:

LATDX_BIN="$(command -v latdx)"
sudo rm "$LATDX_BIN"
sudo rm -rf "$(dirname "$LATDX_BIN")/jars"
rm -rf ~/.latdx              # config, caches, daemons, runner-access permset cache

To remove LATdx artifacts from a Salesforce org as well, see latdx uninstall in the CLI Reference.

See also