Installation
Install the tarski CLI, pin versions, keep it updated, and understand what runs locally versus in the cloud.
Supported platforms
The CLI ships for:
| Platform | Asset key |
|---|---|
| Linux x86_64 | linux-x86_64 |
| Linux arm64 | linux-arm64 |
| macOS (Apple silicon), signed and notarized | macos-arm64 |
| Windows x86_64 | windows-x86_64 |
Some preview releases ship under a scoped distribution; when a platform is intentionally omitted, the installer reports an explicit availability diagnostic naming the platform, version, and distribution scope — never a broken download.
Installing and updating
Releases publish signed, checksummed platform bundles plus channel metadata. Installs
resolve the latest version through the release channel at
https://download.getjacqos.com/channels/<channel>.json, and assets verify against the
published checksums.txt. That download origin is an explicitly retained legacy transport
hostname while release infrastructure moves; installed commands and emitted artifacts use
Tarski identity.
- Pin a version with the
TARSKI_VERSIONenvironment variable. - Update in place with
tarski self-update, which reads the channel’s asset table before constructing a download URL.
Releases are artifact-pinned and immutable: a tag’s assets never change. Defects get a new correction release rather than a mutated old one.
Corporate networks
The CLI uses your host platform’s certificate store plus built-in web roots. For private
CAs, add roots additively with the TARSKI_CA_BUNDLE environment variable or the
--ca-bundle flag. Standard HTTPS_PROXY, ALL_PROXY, and NO_PROXY variables are
honored, with an unconditional loopback bypass. There is no insecure-verification escape
hatch.
What runs where
Tarski’s public development path is cloud-first. Your files, editor, and terminal loop stay local — source discovery, manifest parsing, syntax and schema preflight, diff rendering, and evidence inspection all run on your machine. Protected semantic work — package admission, fixed-point evaluation, provenance construction, deterministic provider execution, and signed evidence — runs in Tarski Cloud or another accepted semantic authority (enterprise runtime, BYOC cell, or an entitled full local runtime).
Practically: tarski dev syncs your source bundle to a cloud dev environment by content
digest, while tarski test and tarski verify keep local ergonomics and return
authority-backed evidence. Output not backed by an authority receipt is labeled
non-semantic preflight or cached evidence — it never silently impersonates a current
pass.