Cmdexa privacy policy and telemetry
Last updated: 29 October 2026
1. Who is responsible
The controller of personal data processed by the Cmdexa service is:
Paweł Meller, a sole proprietor, Kaszubska 7, 81-813 Sopot, Poland, NIP 5833097492, REGON 385413838. Contact: kontakt@cmdexa.com
2. What this policy covers
- the Cmdexa Windows agent and user helper that you install;
- the Cmdexa relay at
relay.cmdexa.comand its dashboard; - the public website at
cmdexa.comandapp.cmdexa.com, including the Cmdexa account pages and Google sign-in.
It does not cover your AI provider (for example ChatGPT). When you connect Cmdexa to an AI client, the client receives the output of the tools it calls and handles it under the provider's own terms and privacy policy.
3. What Cmdexa is, in one paragraph
Cmdexa lets an AI client run read, search and command tools on a Windows computer you choose. The agent on your computer connects outbound to the relay. The relay passes requests from your AI client to the agent and returns results. You can revoke a device at any time.
4. Data we process
| Category | Examples | Where it lives | Why |
|---|---|---|---|
| Device information | device ID, host name, agent and helper version, protocol version, capabilities, executor health, connection state | Relay memory and relay state files | Show which devices are online and route requests to the right one |
| Credentials | device credentials, pairing codes, OAuth client records, OAuth refresh tokens | Relay credential store. Refresh tokens are stored hashed; raw refresh tokens are not kept | Authenticate devices and AI clients |
| Account identity | identity provider issuer and stable subject identifier, Cmdexa account (tenant) ID | Relay account identity store | Associate your Google sign-in with your account and keep devices separated between accounts |
| Account sessions | signed session cookie containing the account ID, identity provider identifiers, account scope and expiry; temporary login-state cookie | Your browser; pending login state is held temporarily in relay memory | Keep you signed in and protect the sign-in flow |
| Setup resume selector | The opaque device ID for the setup attempt selected in one browser tab; no pairing code or device credential | That tab's sessionStorage, with browser-managed retention | Resume the same computer setup after a refresh. The relay still requires a signed session for the owning account and a pending, unexpired code |
| Remembered owner sign-in | An opaque random administrator cookie in the browser; its hash, opaque owner account ID and a cryptographic identity binding on the relay | A protected owner-session store; never raw administrator cookie values on disk | Keep the verified owner signed in without an application timeout; allow durable sign-out and reject sessions after owner identity/key changes |
| Task data | task ID, request ID, device ID, working directory, execution context (run_as), a command preview, a SHA-256 of the command, status, exit code, error code, timing | Relay task store, which can be persisted to a task history file | Run the task, show its progress, diagnose failures |
| Task output | bounded stdout and stderr, output-gap markers | Relay task store, same limits as above | Return results to your AI client |
| Audit entries | stage, device ID, task ID, request ID, command SHA-256, working directory, run_as, policy class, status and error codes. The raw command body is not stored | Bounded, in-memory audit log on the relay | Show what happened and why an action was allowed or blocked |
| Tool history | redacted records of MCP tool calls | Optional JSONL file on the relay, only if the operator enables it | Debugging and support |
| Setup progress | Opaque account/device IDs, allowlisted setup steps, server receipt times and fixed problem codes reported by the browser | A bounded operational history on the relay | Identify where account setup stopped before the first authenticated computer connection. A download click is not proof of a download or installation. We do not put pairing codes, credentials, commands, email addresses, IP addresses or free-text browser errors in this history |
| Connection data | IP address and request metadata, which can appear in ordinary server logs | Relay server | Operate and secure the service |
| Contact messages | your email address and what you write to us | The operator's mailbox. Mail sent to @cmdexa.com addresses is forwarded through Cloudflare Email Routing | Answer you |
We do not collect more than the above to run the service. We do not sell personal data and we do not use advertising trackers.
Google authenticates you when you choose Continue with Google. Cmdexa does not receive your Google password and uses the verified provider identifier to link you to your Cmdexa account. The current account sign-in code does not store your Google email address, name or profile picture. Google handles its own sign-in data under its privacy policy.
Tenant data is separated by account for public MCP users. The relay operator's private administrative API has broader service-wide access: the operator can inspect tenant device and task metadata, task output and artifacts, and can issue commands to connected devices. Whether a command can run as SYSTEM depends on device permissions and local execution settings. Administrative actions are recorded in the relay audit data and are limited to service operation, security and support.
5. What stays on your computer
C:\ProgramData\Cmdexa\agent.json: relay URL, device ID, device credential and optional local limits;C:\ProgramData\Cmdexa\update.log: updater activity;- the installed agent under
C:\Program Files\Cmdexa\and backups the updater keeps for rollback; - the user helper and its local state in your Windows profile (used for
run_as=useractions and local approval prompts); - a local replay spool of recent task output, used to replay output after a reconnect.
Files your AI client reads or writes through Cmdexa stay on your computer unless the AI client reads them and the tool output is returned to it (see section 6).
6. What your AI client receives
Whatever a tool returns goes to your AI client, and from there to your AI provider. That includes file contents you ask it to read, command output, and search results. Cmdexa cannot recall data after it has been returned to the AI client.
Connect Cmdexa only to AI clients and accounts you trust, and only to computers you are allowed to administer.
7. Screenshots
screen_capture_v1 captures one screenshot per request that you approve on the computer itself, every time. The screenshot is saved as a PNG file inside the workspace on your computer. The tool does not return image bytes directly. If your AI client then reads the file with an image-reading tool, the image is returned to that client like any other tool output. Do not capture screens that show information you are not willing to share with your AI provider, or people who have not agreed to it.
8. Redaction, and its limits
Cmdexa redacts secrets in several diagnostic tools (for example configuration reads, environment information, log search and tail, startup items, and the support diagnostics bundle). It also blocks its file-reading tools from returning known credential locations, such as the Cmdexa configuration file, SSH keys, .env files and common credential stores.
These are defensive filters, not a guarantee. They do not protect arbitrary commands run through the execute tools. If you ask Cmdexa to print a secret, it can return it. Do not paste tokens, pairing codes, private keys, cookies or full installer commands into an AI chat or a bug report.
9. How long we keep data
The relay limits what it keeps. The default limits in the Cmdexa software, which the operator can change, are:
- 4 MiB of output per task;
- 1024 replay events per task;
- terminal tasks kept for 1 hour;
- at most 10,000 terminal tasks;
- at most 25 concurrent public tasks per tenant;
- at most 100 stored artifacts and 64 MiB of artifact data per tenant;
- at most 60 public MCP and artifact requests per tenant per minute;
- the in-memory audit log is bounded and is not kept across restarts.
The operator can change the per-tenant defaults through relay configuration.
Setup progress stops being recorded after the first authenticated computer connection. Browser reports cover interface startup, access-choice changes, requesting and displaying pairing instructions, installer-link availability, download and copy actions, expanding the PowerShell alternative, fixed error categories, and the setup page becoming hidden or being left. They contain no copied values, pairing codes, URLs, stack traces or error messages. Hiding a page does not prove abandonment, and clicking a download does not prove installation. Browser reports are best effort, not a recording of the user's screen or installer. Its detailed history is limited to 32 events per account and expires after 30 days, with hourly cleanup and cleanup on access/restart. Repeated identical reports are coalesced. A minimal completion marker is retained while the account is needed so tracking does not restart later. For computers connected before this feature, the marker does not invent an earlier connection date. The setup store is limited to 10,000 accounts and 4 MiB; if it is unavailable, account sign-in, pairing and connections continue without setup-history recording. We do not reconstruct setup steps that were not observed.
Ordinary server logs are kept only as long as needed to operate and secure the service. Contact messages are kept for up to 12 months after the last message. You can ask us to delete data we hold about you (see section 13).
Account identity mappings are kept while your account is needed to provide the service; contact us to request account deletion. Ordinary customer account sessions expire after 15 minutes by default; the operator can configure the account session lifetime. Temporary sign-in state expires after 10 minutes. Logging out clears the account session cookie in your browser.
The configured owner may have a separate remembered administrator session with no application idle or absolute timeout. It remains bound to the currently authorized owner identity and session key. Signing out durably revokes that remembered session; removing the owner authorization or changing the signing key makes it unusable. Browsers may clear or limit persistent cookies, and clearing browser data removes the remembered browser login. Server-side remembered-session records are bounded and are not used for customer sign-in or public MCP access.
10. Who we share data with
- Your AI provider, as described in section 6, because you chose to connect it.
- Hosting provider: Oracle Cloud Infrastructure, region Frankfurt, Germany, which runs the relay server.
- Cloudflare: DNS for
cmdexa.comand email forwarding for@cmdexa.comaddresses. - Email provider: messages sent to
@cmdexa.comaddresses are forwarded to the operator's mailbox at Google (Gmail). - Sign-in provider: Google verifies your identity when you use Google sign-in and returns a verified identity token to Cmdexa.
- Authorities or other third parties only where the law requires it.
The agent and updater connect only to your configured relay (by default relay.cmdexa.com). Cmdexa does not include third-party analytics, advertising or crash-reporting services.
11. Cookies and tracking
The public landing page at cmdexa.com / app.cmdexa.com does not itself set cookies, run scripts or load third-party resources. Account pages use first-party scripts for pairing and managing devices, and the sign-in flow uses necessary first-party authentication cookies: cmdexa_session (by default) and temporary cmdexa_oidc_state_ cookies. These cookies use Secure, HttpOnly and SameSite=Lax protections. They support authentication and sign-in security, not advertising or analytics. The Google sign-in page is operated by Google and may use its own cookies.
The operator's private administrative dashboard is separate from your account page. It keeps the operator's API token in the browser tab's session storage while that tab is open.
12. Legal bases
We process the data above to provide the service you request (performance of a contract or steps before a contract), to keep it secure and reliable (our legitimate interest), and to answer your messages (our legitimate interest or your request). Where the law requires consent, for example for screenshots of other people, you are responsible for obtaining it.
13. Your rights
If GDPR applies to you, you can ask us for access to your data, correction, deletion, restriction of processing, a copy in a portable format, and you can object to processing based on legitimate interest. To use these rights, write to kontakt@cmdexa.com. You can also complain to the supervisory authority, in Poland the President of the Personal Data Protection Office (UODO).
You can also act directly: revoke a device from the dashboard to cut off its access, and rotate its credential to invalidate the old one.
14. Transfers outside the EEA
The Cmdexa relay is hosted in Germany (EU). Cloudflare, which handles DNS and email forwarding for @cmdexa.com addresses, and Google, which provides sign-in and the operator's mailbox, can process data outside the EEA under their own data protection terms. Your AI provider may also process data outside the EEA under its own terms.
15. Security
Connections use HTTPS. Agents authenticate with per-device credentials, OAuth refresh tokens are stored hashed, risky actions can require explicit approval on your computer, and new pairings start in read-only mode. No system is perfectly secure. Report a security problem privately to kontakt@cmdexa.com (see SECURITY.md).
16. Children
Cmdexa is for professional and technical use and is not directed at children.
17. Changes
If we change this policy in a way that matters, we will update the date above and, for registered users, tell them in advance.