Telemetry
Last updated: October 1, 2026
Summary
Official MXterm Pro builds send anonymous usage reports, and they are on by default. They tell us how many people run the app, which versions are in use, and which failures happen most, so we know what to fix next.
Reports never include terminal output, commands, file contents, file paths, SSH hosts or usernames, or license keys. You can turn reporting off in Settings → Privacy, or with an environment variable, and builds you compile yourself send nothing.
From version 1.1.12 they also include counts and ranges of how features are used, never what you typed or opened. The Usage counts block below lists every field.
What we collect
As of MXterm Pro 1.1.11 there are three reports, and this lists every field in each one. From version 1.1.12 a fourth block, usage counts, is sent with the daily check-in and listed last.
1. Usage ping
- Sent to
- Google Analytics (www.google-analytics.com)
- When
- One app_open event at launch, and nothing else for the rest of that run.
| Field | What it contains |
|---|---|
| client_id | A random ID created on first launch and kept in a file named telemetry-id |
| event name | app_open |
| session_id | The time the app was launched, in seconds |
| engagement_time_msec | A fixed number: 100 |
| app_version | The MXterm Pro version |
| os | The operating system name, for example macos |
Google infers an approximate country from the IP address the request comes from.
2. Daily check-in
- Sent to
- mxterm.net, our own server
- When
- When the app starts, if 24 hours have passed since the last check-in, or straight away if the previous run crashed. An app left open for days checks in again at its next launch.
| Field | What it contains |
|---|---|
| installId | A random ID kept in a file named telemetry-install-id. We store a hash of it, not the ID itself |
| currentVersion | The MXterm Pro version |
| tier | free or pro |
| telemetryEnabled | Always true, since the report is only sent when reporting is on |
| osVersion | The macOS version, for example 15.5 |
| arch | arm64 or x64 |
| platform | mac or windows |
| crashedLastRun | Whether the previous run ended without shutting down cleanly |
| sessionsSinceLastCheck | How many times the app was opened since the last check-in |
| paywallShown | How many times each upgrade prompt was shown, by prompt name |
| paywallClicked | How many times each upgrade prompt was clicked, by prompt name |
The prompt names are locked_panes, locked_ssh_hosts, locked_war_room_members, locked_mxterm_hosts, locked_my_devices, locked_access_password, locked_email_share, locked_remote_devices, locked_shared_panes, settings_license_panel, titlebar_menu and command_palette.
3. Failure events
- Sent to
- mxterm.net, our own server
- When
- When one of the specific failures listed below happens: eight in MXterm Pro 1.1.11, and seven more from version 1.1.12. Events that can't be sent are queued, up to 50, and retried later.
| Field | What it contains |
|---|---|
| eventId | A random ID for this event |
| installIdHash | A hash of the install ID from the daily check-in |
| occurredAt | When it happened |
| eventType | One of the events below |
| severity | warning, or critical for a crash or a license lost after activation |
| detail | The extra detail listed below, and nothing else |
| app version, OS, arch | The MXterm Pro version, operating system and processor type |
Reason codes are chosen on your Mac by matching the error, and the error text itself is never sent. For SSH, SFTP and the editor the reason is one of auth_denied, password_expired, host_unreachable, timeout, permission_denied, not_found, disk_full, network or unknown. For license failures it is a short code such as bad_signature or expired, sometimes the code our license server returned, or seat: followed by a code when an activation through your MXterm account fails.
4. Usage counts (from version 1.1.12)
- Sent to
- mxterm.net, our own server
- When
- Once a day, in the same request as the daily check-in, from version 1.1.12. No usage counts are sent while usage reporting is off.
| Field | What it contains |
|---|---|
| schema | The version of this list of fields, currently 1 |
| milestones | Each one is sent once and never again, as a flag without a date, and is recorded only while usage reports are on: onboarding (completed or skipped), firstPane, firstSplit, firstSshHost, firstSftpOpen, firstRemoteShare, firstLicenseActivation (a license was activated on this Mac, with a key or through your MXterm account), firstShortcutCustomized (you set a custom keyboard shortcut), firstAgent (the agent's name from the fixed list, or other) and firstImport (ssh_config, moba, iterm2 or session_json) |
| daysSinceInstall | Days since install, as a range: 0, 1, 2 to 6, 7 to 29, 30 to 89 or 90 and over |
| counters | Whole numbers from 0 to 100000, counted since the last check-in that went through and then reset: panesOpened, splits, warRoomRooms, sshConnects, sftpTransfers, worktreePanes, paletteOpens, remoteHostStarted, chatViewOpens, meshPeerConnects and myDeviceLinks. Panes restored when the app opens are not counted, sftpTransfers counts downloads only, remoteHostStarted counts only when you press Start yourself, chatViewOpens counts each time a pane is switched to Chat view, meshPeerConnects each successful connection to a peer on the experimental network feature, and myDeviceLinks each device you link under My Devices |
| agentLaunches | How many times each agent was launched, by name from the fixed list. A name not on the list is counted as other |
| importsBySource | How many imports came from each source: ssh_config, moba, iterm2 and session_json |
| sftpBytes | How much SFTP data was downloaded, as a size range: 0, under 1 MB, under 100 MB, under 1 GB or 1 GB and over. Downloads only |
| pairedDevices | How many devices are paired, as a range: 0, 1, 2 to 4 or 5 and over |
| language | The interface language: en, vi, zh, ja, ko, es, fr, tr, id, pt, de or other |
| theme | The theme: one of the built-in themes iterm2-pro, vscode-dark, iterm-dark, tokyo-night, catppuccin, one-dark, monokai-pro, solarized-dark, mxterm-classic, mxterm-2, mxterm-light or warm-paper, or other |
| coldStartMs | Cold start time, as a range in milliseconds: under 500, under 1000, under 2000, under 4000 or 4000 and over |
| firstPromptMs | Time to the first prompt, as a range in milliseconds: under 100, under 300, under 1000 or 1000 and over. Local shells only |
| rssMb | Memory in use, as a range in MB: 0 to 200, 200 to 500, 500 to 1000, 1000 to 2000 or 2000 and over. Only MXterm's own processes are counted |
| paneCount | How many panes were open, as a range: 1, 2 to 4, 5 to 9 or 10 and over |
| hiddenTimerGapMs | How late the app's timers ran while the window was hidden, as a range: under 1 second, under 5 seconds, under 30 seconds or 30 seconds and over |
| ptyBurst | The highest terminal output rate seen that day, in chunks per second, as a range: under 100, under 1000, under 10000 or 10000 and over |
The lists are fixed. Agents are claude_code, codex, gemini_cli, cursor_agent, opencode, github_copilot, amp, antigravity, omp, grok and other. A value that is not on a list is sent as other. The other performance values are the middle range of the day's samples. Performance is sent once a day. Usage counts are kept for 400 days. We report only groups of at least 10 installs.
The failure events
| Event | Extra detail sent |
|---|---|
| ssh_connect_failed | A reason code. Sent when listing a remote folder over SFTP fails |
| sftp_transfer_failed | Whether it was an upload or a download, and a reason code |
| editor_read_failed | A reason code |
| editor_save_conflict | Nothing |
| license_activation_failed | A reason code |
| license_lost_after_activation | A reason code: bad_signature, not_paid_tier, hwid_mismatch, expired, revoked, machine_inactive, refunded, invalid_license or no_seat |
| crash_recovered | From version 1.1.56: two closed words: where the app was when it stopped (one of boot, restore, running, voice, quit, network or other) and how long it had been running, in a bucket from under 1 minute to over 1 day |
| ui_crashed | The React error number, or other |
| pty_spawn_failed | From version 1.1.12: a reason, one of shell_missing, permission or other; from version 1.1.56 also cwd_missing and resource_limit |
| agent_not_found | From version 1.1.12: which agent, by name from the fixed list, or other |
| update_failed | From version 1.1.12: the stage, one of download, signature, install or other; from version 1.1.56 also check (the update check itself failed), with a class: network, manifest, http_4xx, http_5xx or other (a refused check is currently classed manifest) |
| remote_attach_failed | From version 1.1.12: a reason, one of auth, network, stale, revoked or other |
| worktree_failed | From version 1.1.12: a reason, one of not_repo, exists, git_error or other |
| keychain_failed | From version 1.1.12: the operation, one of read, write, denied or other |
| import_failed | From version 1.1.12: the import source (ssh_config, moba, iterm2, session_json or other) and a reason, one of none_found, invalid, read_failed or other |
What we never send
- Terminal output or scrollback
- The commands you run
- File contents or file paths
- SSH hostnames, usernames, passwords or keys
- License keys
- Anything from your clipboard or screen
All three reports are checked just before they are sent: if a report contains a string that looks like a home folder path, an SSH key, a license key, a password, a token or a secret, the whole report is dropped instead of sent.
From version 1.1.12 the usage counts never contain paths, host names, commands, file or repository names, branch names, keys, prompts or terminal output. If they look like they hold a path, key or token, the whole report is dropped.
Since MXterm Pro 1.0.22 the usage ping to Google Analytics goes through that same check. It is built only from the six fields listed above, none of which can carry your data, and it would be dropped rather than sent if one of them ever did.
Failures are also written to a list kept only on your Mac, the newest 200, and nothing older than 14 days, whether reporting is on or off. That list is a separate file from the send queue and is never uploaded; it exists so that a diagnostic file can describe what went wrong.
MXterm Pro also keeps a second local file, war-room-delivery.jsonl, in its app data folder. For each Control Room (formerly War Room) message it records why the message was held, released or dropped before it was typed into a pane: the time, the event, the reason, how many messages were waiting, how long they waited, and a short code for the pane (a hash, not the terminal id, shown as the peer-… name Control Room uses). It holds no names, paths, message text or terminal ids. It keeps at most 500 lines or 30 days, is never uploaded and is not part of the diagnostic file.
How to turn it off
Open Settings → Privacy and switch off Share anonymous usage data. Switching off takes effect immediately for all three reports: the switch is re-read just before every send, not at launch.
From version 1.1.12 the same switch also controls usage counts, and turning it off stops new usage reports. The first time you run that version, a one line notice tells you about them and where to turn them off.
You can also turn it off with an environment variable: DO_NOT_TRACK or MXTERM_TELEMETRY_DISABLED. Any value counts as off except 0, false or no, in any capitalisation. Both variables are read before every send, and while one of them is set the switch in Settings is disabled and names the variable that turned reporting off.
Switching back on takes effect without restarting the app. Failure events held from before and a daily check-in that is due are sent straight away, and the usage ping resumes within about fifteen seconds. Nothing is queued for sending while reporting is off, so a failure that happened during that time is never sent.
To start over with new random IDs, quit MXterm Pro and delete telemetry-id and telemetry-install-id from ~/Library/Application Support/com.mxterm.desktop/.
Builds you compile from source contain none of this reporting: the keys it needs are added only when official releases are built.
Where the data goes
The usage ping goes to Google Analytics and is processed by Google, including in the United States.
The daily check-in and failure events go to mxterm.net, which runs on our own server in France, hosted by Contabo and served through Cloudflare. For each install we keep one record with the fields above and the country the request came from; we do not store the IP address. Failure events are kept with the country too. These records are not currently deleted automatically.
From version 1.1.12, usage counts also go to mxterm.net, inside the daily check-in, and are kept for 400 days. We report only groups of at least 10 installs.
The diagnostic file goes nowhere on its own. Settings → Privacy → Diagnostic file for support → Save file… builds a file named mxterm-diagnostics-YYYY-MM-DD.json and asks you where to save it. It holds the app version, whether this is an official build, how long this run has been going, Free or Pro, the operating system, its version and the processor type, whether reporting is on, the interface language, whether the previous run crashed, counts of saved SSH hosts, open tabs and open panes, which agent templates are in use, which Token Meter providers have a key configured, and the local list of recent failures. Your home folder is folded to ~ before it is written, the whole file goes through the same check a report does and is refused outright if it trips it, and nothing is uploaded: you read the file and decide whether to email it to support.
Other network calls the app makes
These are not usage reports, so the usage switch above does not affect them. Those you can turn off have their own switch, named in the entry; the update check, the Free limits check and the license checks have no switch.
- Update checks
- Shortly after launch and every four hours, the app asks mxterm.net whether a newer version exists, sending its current version, your operating system and interface language. This happens in every build, including ones you compile yourself. When usage reporting is off, a check can still leave one anonymous record on our server: the app version, the country, whether an update was available and whether the app is Free or Pro, with no IP address and no install ID. Each update check is also counted by app version and country, with no identifier, to show how many copies are running.
- License activation
- When you enter a license key, the app sends the key, a machine fingerprint made from part of a hash of your computer's hardware UUID, your computer's hostname, the app version and the platform. If usage reporting is on, activating a license (with a key or through your MXterm account) also sends the app's random install ID (the one in the daily check-in), so we can match a paid license to that install's usage numbers. If usage reporting is off, no install ID is sent.
- License re-check
- At launch (at most once an hour) and then about once a day while you are online, the app sends the license key, the machine fingerprint and the app version to ask whether this machine is still licensed. If you activated through your MXterm account instead of a key, it sends the machine fingerprint, the machine name, the platform and the app version with your account session. A check that fails or finds you offline changes nothing; only a clear answer that the license or seat is gone, given twice in a row, removes Pro from the app. The server keeps each machine's last-seen time and app version, not a history of checks.
- Free limits
- Shortly after launch and every four hours, the app asks mxterm.net for the current Free plan limits. The request carries no install ID and no data about you, only what any request reveals, such as your IP address. This happens in every build.
- MXterm account and My Devices
- Only when you sign in with a MXterm account. The app keeps a sign-in token in your Keychain and, for My Devices, sends mxterm.net a device ID, this computer's name and public keys, and asks for your device list about every five minutes. About once a minute it also sends a presence update, encrypted for your other devices so that mxterm.net cannot read it: the network address where this computer's host server can be reached. mxterm.net sees the device ID, the time and the IP address of the request. Signing out stops these requests. What the server stores is listed in the privacy policy.
- Experimental network feature
- Only when you switch on the experimental network feature (macOS, invited testers). The app's helper connects to mesh.mxterm.net, which introduces your devices to each other, and to the relay sg.relay.mxterm.net. Both run on AWS in Singapore. The relay sees device public keys and source IP addresses, not terminal content, which is encrypted between your devices. Peers on the same mesh see each other's device name, operating system and addresses. Signed in, the app also asks mxterm.net for a one-use enrollment key. Details are in the privacy policy.
- Claude plan limits
- Off by default. If you turn on Plan limits in Settings → Token Meter, the app reads Claude Code's saved sign-in from your Keychain through the macOS security tool (macOS does not normally show a prompt for it), and uses it to fetch your usage limits from api.anthropic.com, at most once every five minutes.
- Live Codex limits
- Off by default. If you turn on Live Codex limits in Settings → Token Meter, the app reads Codex's sign-in from ~/.codex/auth.json and sends it only to chatgpt.com, to read your current 5-hour and weekly limits, at most once every five minutes. It never changes or refreshes that sign-in, and a sign-in Codex keeps in the system keychain is not read.
- Account provider balances
- Off until you add a key. In Settings → Token Meter you can paste an API key for DeepSeek, Moonshot, Kimi, MiniMax, OpenRouter or Z.ai. Keys are kept in the macOS Keychain, in items MXterm Pro creates itself under the service name MXterm Pro, and each key is sent only to its own provider: api.deepseek.com, api.moonshot.ai or api.moonshot.cn, api.kimi.com, api.minimax.io or api.minimaxi.com, openrouter.ai, and api.z.ai or open.bigmodel.cn. The request only reads your balance or quota, and carries nothing but the key: no prompts, no transcripts, no file names. Each provider is asked at most once every five minutes, and nothing is asked at all until at least one provider is configured. For Kimi alone, if no key is saved and the Kimi Code CLI is signed in on this Mac, the app reads that CLI's token and the device id stored beside it from ~/.kimi-code and sends them to api.kimi.com in the same way; it never writes to that directory and never refreshes the token.
- Token Meter
- Claude Code, Codex, Gemini CLI and omp token counts, and the plan percentages Codex itself writes into its session files, are read from files those tools keep on your Mac. Nothing is sent.
- Feedback
- From 1.1.57 on Mac (1.1.58 on Windows and Linux), Settings → Feedback sends your name, email, message, kind, app version, system and language to mxterm.net when you press Send, plus the diagnostic file only if you tick it (kept 90 days). It is processed by our email provider. Older versions open your mail app instead and make no request to mxterm.net.
- Remote access
- Off until you use it. The host server does not run until you press Start Server in Settings → Remote Access & Devices, unless you turn on Start the host server when MXterm opens, which is off by default. It then listens on port 6868 (or the next free port up to 6877) on your Tailscale address if there is one, plus your private network addresses if you turned on Allow devices on my local network, and otherwise on this Mac only. Never on a public address. On a private network the traffic is not encrypted. Paired devices can reach only the panes you share. A pane is shared as view only or with control, and a device can type only in a pane shared with control. A new device pairs with a six-character code or with an access password you turn on; the password itself is never sent on later connections, and when it is sent it goes to a Tailscale address, to the local proxy of a peer on that experimental network or, if you allow local network access, to a local-network address, where it is not encrypted. While the server runs and a pane is shared, MXterm Pro keeps the computer from going to sleep on its own (built for macOS and Windows; the Windows side is unverified) unless you turn that off. If you add a host under Machines, the app connects to that host's address with a token kept in the macOS Keychain, and pairing with that host's password sends the password to a Tailscale address, to the local proxy of a peer on that experimental network or, if you allow local network access, to a local-network address, where it is not encrypted. Terminal content never goes through mxterm.net. If you use My Devices, mxterm.net only handles the device list and presence described under MXterm account and My Devices.
- Tailscale guide video
- Only if you press Play in the Tailscale guide in Settings: the video then loads from YouTube (youtube-nocookie.com). If you do not press Play, the app makes no connection for it.
- Your own connections
- SSH, SFTP and anything you run in a terminal connect where you point them. Tools you run inside MXterm Pro, such as Claude Code or Codex, make their own network calls; those belong to those tools, not to MXterm Pro.
The privacy policy covers the rest, including what mxterm.net records when you buy or download.
Ask AI about MXterm Pro
Open a live answer in ChatGPT, Claude or Perplexity, based on this page. The assistant writes it, not us, so check the sources it cites.
Question sentWhich usage counts does MXterm Pro record, what does it never record, and where does the data go?