Last updated: August 1, 2026

Privacy Policy

This policy explains how ctx handles information for the public documentation site, support channels, and the ctx local search CLI.

Local CLI data

ctx is a local CLI for indexing existing coding-agent session history into a self-contained Tantivy Core and searching it from your machine. Setup, source discovery, and import read local provider inputs. Search, show, locate, and transcript output read local ctx Core storage for transcript content.

The CLI may store sensitive developer history locally, including prompts, responses, code snippets, command text, command output previews, file paths, working directories, session metadata, and normalized searchable text. Treat the ctx data root, Core index, local database sidecars, logs, and written JSON or transcript output as private developer data.

By default, the ctx data root is ~/.ctx. You can choose a different root with CTX_DATA_ROOT or --data-root.

CLI analytics

The ctx CLI uses default-on product analytics for coarse command invocation metadata, including install-triggered setup runs. This helps us understand which commands are used, whether they succeed, and where the CLI needs improvement. CLI analytics are sent to https://cli.ctx.rs/functions/v1/analytics.

The CLI analytics field allowlist includes generated data-root and client-profile identifiers (stored as server-side hashes), ctx version, OS, architecture, typed surface and operation names, success state, duration bucket, option booleans, bucketed counts, selected provider filters, and coarse network geography derived by hosting infrastructure. When analytics are enabled, normal setup, import, search-refresh, and daemon work can also report that ctx passively detected or refreshed a provider from a closed provider-family list, even if you did not select a provider or provider filter. Provider telemetry is limited to closed categories for refresh context, lifecycle, outcome, and failure plus bucketed corpus and work measurements. Closed provider families remain eligible for collection even when they are rare or low usage; collection does not use a popularity threshold. For less than seven days after an official hosted installation, eligible product-analytics events may also include the installer attempt identifier so we can measure initial activation; the server stores it only as a hash. ctx omits this bridge at the seven-day boundary and whenever the install timestamp is missing, malformed, or in the future. Managed upgrades preserve the original timestamp rather than reopening the window.

CLI analytics do not include history or transcript content, prompts, responses, source code or source bodies, indexed search content, search query text, MCP request parameters or tool-result content, result snippets, source or repository paths, locators or native coordinates, repository or branch names, raw local or provider source/session/event/record/resource IDs or hashes of them, exact corpus counts, byte sizes, text lengths, timestamps, durations, CPU, memory, or I/O measurements, raw error messages, command text, command output, credentials, authorization headers, access tokens, secrets, or SQLite database contents. Counts, sizes, lengths, durations, and resource measurements are omitted or bucketed before transmission. Setup, import, search, show, locate, and transcript output do not send indexed transcript content to a model API as part of normal CLI operation. CLI and MCP operations may send only bounded typed operation metadata under this allowlist, such as input or output kinds, outcomes, duration or count buckets, truncation booleans, and lifecycle state.

To disable CLI analytics persistently, set [analytics] enabled = false in config.toml. To disable analytics for one process or installer run, set CTX_ANALYTICS_ENABLED=false. A config opt-out wins over CTX_ANALYTICS_ENABLED=true and an endpoint override.

Installer diagnostics

The official shell and PowerShell installers separately send default-on diagnostic stage reports to https://cli.ctx.rs/functions/v1/install-attempt. The exact install_stage@1 payload allowlist is event_name, event_version, install_attempt_id, stage, status, platform, arch, and script_family. The anonymous per-response attempt identifier is stored only as a server-side hash.

Installer diagnostics do not include history or transcript content, prompts, query text, source code or source bodies, source or repository paths, credentials, authorization headers, access tokens, secrets, command output, or downloaded file contents.

Set CTX_ANALYTICS_ENABLED=false before running the installer to disable both installer diagnostics and CLI analytics during setup.

We process CLI analytics and installer diagnostics only through their respective field allowlists. We keep these records only as long as needed for product operations, security, support, abuse prevention, legal compliance, and aggregate reporting.

Anonymous ctx pro trial

An eligible fresh interactive install starts the anonymous 14-day ctx pro trial automatically after Core setup. No account or payment card is required. Use --no-pro-trial, PowerShell -NoProTrial, or CTX_INSTALL_NO_PRO_TRIAL=1 for an explicit Core-only install. CI, unattended, machine-readable, no-setup, no-daemon, and managed rerun paths remain Core-only.

Activating the trial is a network exception to otherwise local setup. The CLI contacts the first-party anonymous-trial service to establish and evaluate the trial and stores installation-bound trial and anti-rollback state in the operating system's native key store. That state is not transcript content, a graph key, an account token, or an entitlement body. Declining the trial does not make this trial-service request.

The release-signed trial helper derives challenge- and installation-bound opaque digests from a random anchor stored in the native key store and available OS-install, firmware, and board identifiers. Raw identifiers are normalized and application-HMACed locally; they are not sent to ctx or logged. The anonymous-trial service applies an independent, versioned server HMAC and retains only anti-repeat lookup tokens and the minimal deadline and lifecycle data needed to enforce the one-trial policy.

This is best-effort abuse prevention, not hardware identity or attestation. Raw anonymous-device evidence and its anti-repeat fingerprint are not joined to analytics, history, paths, identity, or billing data. A confirmed ctx pro uninstall --delete-data removes the client anchor and trial credentials from local native-vault storage, but it does not remove the minimal server-side consumed-trial tombstone retained for the one-trial policy.

Referrals and payouts

Referral codenames are public. Do not put private information in a codename. When someone explicitly starts a referred trial with ctx pro --referral <codename>, we store a bounded referral ledger so we can apply one direct immutable attribution, verify qualifying paid invoices, and administer invoice-level commissions. The ledger may contain public codename ownership; the relevant WorkOS subject and personal-organization coordinates; a verified-email digest; trial claim and attribution identifiers; Stripe customer, subscription, invoice, charge, payment-intent, recipient, payout, and payout-batch references; bounded idempotency and webhook-event records; and the timestamps, amounts, invoice ordinals, hold deadlines, reconciliation results, review reasons, commission revisions, negative adjustments or debt, and payout state needed to administer the program.

The referral ledger does not contain transcripts, prompts, source code, Git data, repository data, raw anonymous-device evidence or fingerprints, payment card details, or bank details. At launch, payout recipients are individual people only. Before creating the single Stripe recipient, interactive setup collects the person's country; an advanced machine-readable caller may supply a two-letter country code. ctx does not infer country from identity, organization, email, IP address, billing information, or any other signal. Stripe collects payout onboarding, identity, tax, and bank details in its hosted flow; ctx receives only the recipient reference and payout status needed to administer aggregate manual payout batches. ctx does not create a new payout-recipient relationship for every invoice or referral.

An accepted referral claim is separate from anonymous-device evidence. If the referred trial converts to a paid subscription, that explicit claim can be joined to the WorkOS and Stripe references needed for attribution and commission processing. The underlying raw device evidence and fingerprint remain unjoined from identity and billing.

Referral status is available only to the authenticated referrer and is aggregate. It does not identify referred people or expose their invoice-level activity. Its accounting separates accrued cash awaiting manual review, payable cash, sent-but-unsettled processing cash, historical settled cash, and the nonnegative debt balance created by post-paid reversals. ctx does not use a referral site, tracking link, browser cookie, or creator-affiliate tracking profile for attribution.

Upgrade checks

Official installer-managed binaries can contact ctx release metadata endpoints for explicit ctx upgrade operations. Only daemon maintenance performs background auto-upgrade checks; ordinary foreground commands do not trigger automatic upgrades. Upgrade checks are intended to send only ordinary HTTP request metadata plus release channel/platform context; they are not intended to upload transcript text, search queries, snippets, source paths, repository names, command output, or SQLite contents. Disable managed background auto-upgrade with ctx upgrade disable or CTX_UPGRADE_AUTO=off.

Public site and support

When you use the public docs site or contact us, we may receive information such as your email address, support messages, issue reports, diagnostics you choose to provide, IP address, browser and device metadata, referring pages, pages viewed, and basic site usage data.

Do not send unnecessary secrets, credentials, customer data, proprietary code, private transcripts, SQLite databases, logs, or written ctx output in support messages.

Third-party providers

ctx indexes history created by third-party coding agents and developer tools. Those providers control their own products, storage locations, network behavior, terms, and privacy practices. You are responsible for understanding the providers you use and for deciding what local history ctx should index, write to files, or share.

Contact

For privacy requests, email [email protected]. We can respond for data that ctx controls, such as support records and first-party analytics. Local CLI data remains on your machine unless you choose to send it somewhere.