Security and data handling
Security and data handling
Section titled “Security and data handling”CMX is a local gateway, but a model request still travels to the model provider you selected. The data path is:
Coding client → CMX on loopback → selected model providerCMX Cloud is not in that request path. It receives aggregate usage metrics, not prompts, responses, source code, session data, or provider API keys.
Gateway access
Section titled “Gateway access”The gateway binds to 127.0.0.1 by default and rejects non-loopback listen addresses. Local management routes also require an owner token and validate Host and Origin. Binding to loopback does not turn a provider API into a public endpoint.
Credentials
Section titled “Credentials”Your coding client owns provider sign-in. CMX forwards provider credentials in memory for requests and does not persist or log provider API keys. The native client may store its own authentication files according to that client’s design; CMX does not delete them on logout or uninstall. cmx login is a separate, optional CMX account sign-in for the dashboard.
Do not place provider API keys in config.json, terminal screenshots, issue reports, or support emails.
What is stored locally
Section titled “What is stored locally”CMX keeps local configuration, usage and session records, compression metadata, and cached summaries in its user data directory. It does not offer raw request logging; cmx logs describes the available diagnostics. The lossless content vault is enabled by default (compression.vault.enabled: true). Original tool content removed or truncated by local optimization passes is safely archived in the local SQLite database. cmx vault list and cmx vault show <id> can inspect that content; cmx vault prune enforces its retention count. Individual entries can be removed with cmx vault delete <id> or purged entirely with cmx vault clear. See Content vault. To review or remove stored session history, use cmx sessions list and cmx sessions show <id>, then cmx sessions delete <id>, cmx sessions purge, or cmx sessions clear. See Local sessions. Treat the data directory as sensitive and use owner-only filesystem permissions.
cmx uninstall removes CMX’s local data by default. --keep-data retains it. See Undo and uninstall.
Cloud and updates
Section titled “Cloud and updates”Local proxy use does not require a CMX account. An account is needed for account-linked dashboard statistics. The only data sent to CMX Cloud is an allowlisted set of aggregate counters (such as processed tokens, estimated saved tokens, and cache rates) — never prompts, responses, source code, or session data.
When you sign in, these counters are signed, associated with your account, and populate your web dashboard. When you run CMX locally without signing in, the same counters are sent as anonymous aggregates isolated from any account. Delivery is best effort in both modes: if it fails or is unavailable, local compression and proxy traffic continue uninterrupted. Update checks do not install a new binary automatically; cmx upgrade --install is an explicit action. Published binary downloads include SHA-256 checksums. A checksum verifies a file against the published checksum manifest; it is not a code-signing claim.
For suspected vulnerabilities, contact hello@compressi.us without sending live credentials or private conversation content.