Security and Privacy
How Treq handles your data, what it never sends, and which operations the CLI refuses to perform.
Treq is privacy-focused by default. It is a local desktop application. Repository data, workspace metadata, and settings stay on your machine. The base application does not upload your code or feature usage to Treq servers.
Telemetry
Treq does not collect usage telemetry. The application does not send feature usage, crash reports, or performance metrics to Treq or any third party. It does send an anonymous update check, and treq.dev counts those checks to estimate how many desktop installs are active.
Local logs can exist on disk for debugging. They stay on your machine and are not uploaded.
Update Check
About 2.5 seconds after a Treq window loads, the app sends one GET request to https://treq.dev/version. The response is the version number of the latest release. Help → Check for Updates... sends the same request on demand.
When that release is newer than your build, Treq shows a toast. On macOS, Install and restart downloads and installs it. On Windows and Linux, Download opens the latest release on GitHub.
The request identifies your build only through its User-Agent header:
treq/0.3.0 (macos; aarch64)
The header holds the app version, the operating system, and the CPU architecture. The operating system is macos, windows, or linux. The request carries no cookies, account ID, or install ID, so it does not tell one install apart from another.
treq.dev keeps only daily counts of update checks per version and platform. It does not store IP addresses.
To stop the request, turn off Check for updates in Settings → Application. Setting the environment variable TREQ_DISABLE_AUTO_UPDATE=1 before you launch Treq also stops it. With either one off, Treq sends nothing to treq.dev/version, and Check for Updates... reports that update checks are off.
Local Data
The base Treq app stores nothing on remote servers. Workspace checkouts, review comments, terminal session metadata, and app preferences live in local files on your computer.
Repository history remains in your Git and Jujutsu stores. Treq metadata lives under .treq inside the repository and in the app data directory. See Under the Hood for the storage layout.
When Treq connects to a remote Git host, the connection goes directly to that host. Traffic does not pass through Treq servers.
Optional GitHub Integration uses two extra paths. Pull request, issue, CI, and review-thread actions run through the local gh CLI with your GitHub credentials on the machine. Repository linking uses the Treq GitHub App and Treq's backend after you sign in and install the App. Local review comments, application logs, and telemetry all stay locally on disk unless you copy or send them to the Treq developers explicitly.
CLI Safety
The treq CLI is non-destructive. It can create and inspect workspaces, move changes, and start agent sessions. It does not delete workspaces. It does not force-push to remotes.
Workspace deletion stays in the desktop UI, where you confirm context before removing local state. The CLI has no force-push path.
Website Analytics
The documentation site at treq.dev uses Google Analytics to measure traffic. IP addresses are anonymized before Google records them.
This analytics applies only to the website. Visiting the docs does not connect to your local Treq install or repositories.
Open Source
Treq is fully open source. You can read every line of the desktop app, CLI, and documentation site in the public repository.
Audit the code yourself, or follow the public history of changes. These files are the direct sources for the claims on this page:
| Claim | Source |
|---|---|
| Telemetry stays on disk | src-tauri/src/telemetry.rs |
Update check request and User-Agent | src-tauri/src/core/auto_update.rs |
| App and repository databases | src-tauri/src/db.rs, src-tauri/src/local_db.rs |
| CLI command set | src-tauri/src/cli/mod.rs |