Install and Update the CLI

The CLI is one JavaScript file with no runtime dependencies. It needs Node 22 or newer, and it runs on macOS, Windows and Linux. All three run the full test suite on every change, because the failures a local binary has are mostly platform-shaped.

Install it globally#

npm install -g @stringlane/cli

Then:

stringlane --version

This is the right choice for a machine you work on: the command is on your PATH, so your shell, your agent and any script can reach it by name.

Or run it without installing#

npx @stringlane/cli@latest check .

Keep the @latest. Named without a version, npx runs any copy of @stringlane/cli already installed in the project or globally, however old it is, so a global install from months ago answers instead of the current release. @latest makes npx ask the npm registry for the current version on every run.

Useful for trying it once, and for a CI job you would rather not add an install step to, where you put an exact version in place of latest, because a minor version of a 0.x CLI is allowed to change its commands. It costs a resolution on every invocation, so it is the wrong default for interactive use.

Pin it in CI#

The CLI is at 0.x. That is not modesty, it is notation: the command surface is not promised yet, so a minor version is allowed to change it. In a pipeline, name the version you tested against.

- uses: actions/setup-node@v4
  with: { node-version: 22 }
- run: npm install -g @stringlane/cli@0.9.0
- run: stringlane check .

Upgrade that number deliberately, when you have read what changed.

Keep it current#

npm install -g @stringlane/cli@latest

The CLI is versioned on its own clock, separately from the desktop app: they ship when each has something to ship, and the numbers are not meant to line up. Updating one never requires updating the other.

Remove it#

npm uninstall -g @stringlane/cli

That is the whole removal, with two things worth knowing about what it leaves behind.

Your repository is untouched. What StringLane wrote there are your files, committed and readable without StringLane:

• stringlane.yaml, from init;
• .stringlane/baseline.yaml, from baseline write;
• .stringlane/metadata.yaml, from describe and the desktop app's metadata panel;
• .stringlane/source-stamps.json, from init, accept and apply when sourceStamps: true is set;
• .agents/skills/stringlane-*, one folder per skill, from setup skills --apply. stringlane setup skills --remove deletes the copies nobody has edited, so run it before you uninstall if you want those gone.

Delete them if you want them gone. Remove sourceStamps: true from stringlane.yaml along with the stamps file, or a later check with StringLane installed again exits 2.

A small state directory remains. StringLane keeps its own state outside your repository, in the usual per-user location for your platform:

It holds:

• install.json: a random install ID, your stringlane telemetry setting, and when the first-run notice was shown. The first command you run creates it (any command but hook), stringlane telemetry status included, and a run after stringlane telemetry off keeps it. With DO_NOT_TRACK=1 or STRINGLANE_TELEMETRY=0 set, or on a CI runner, nothing is written to this directory at all, so no ID is created; telemetry status then reports random install ID: none. An ID saved by an earlier version is never sent while one of those is set, and you can delete the file.
• update-check.json: when the CLI last asked the npm registry for the latest version, and the answer. The once-a-day background check does not write it when STRINGLANE_NO_UPDATE_CHECK=1, DO_NOT_TRACK=1 or STRINGLANE_TELEMETRY=0 is set, or on a CI runner; stringlane telemetry off does not stop that check, and stringlane upgrade writes the file whatever is set.
• projects/<hash>/, one folder per project, named by a hash of the project path:
  • usage-cache-v1.json, from check, scan and the MCP server: each scanned source file's path inside the project, its size and modification time, and every key name found in it with its line number.
  • apply.lock and state-v1.json: the apply lock, a record of what the project looked like last time, and a fingerprint of each translation apply or update wrote, so plan can offer it again when its source text changes.
  • hook-snapshot-*.json, from stringlane hook during an agent session: a hash of each locale file, so it can tell whether something other than StringLane changed one.

Deleting it leaves your projects as they are, and StringLane rebuilds what it needs on the next run, with two costs. It forgets which translations earlier applies wrote, so without source stamps those are no longer offered again when their English changes; with sourceStamps: true, the committed stamps file in your repository decides that instead. And it resets stringlane telemetry off: the next command shows the first-run notice again and sends usage data, unless STRINGLANE_TELEMETRY=0, DO_NOT_TRACK=1 or a CI runner says not to. Set STRINGLANE_STATE_HOME to an absolute path to put it somewhere else, which is worth knowing on a CI runner or in a container with no writable home directory.

If you also use the agent plugin#

On macOS and Linux the plugin can find the CLI for you. On Windows it cannot: the bundled resolver is a POSIX shell script and Windows will not run it. Install the CLI globally yourself once, as above, and the MCP server and hooks then behave identically. See Agent hosts.