Cmdexa← Back to Cmdexa

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.com and its dashboard;
  • the public website at cmdexa.com and app.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

CategoryExamplesWhere it livesWhy
Device informationdevice ID, host name, agent and helper version, protocol version, capabilities, executor health, connection stateRelay memory and relay state filesShow which devices are online and route requests to the right one
Credentialsdevice credentials, pairing codes, OAuth client records, OAuth refresh tokensRelay credential store. Refresh tokens are stored hashed; raw refresh tokens are not keptAuthenticate devices and AI clients
Account identityidentity provider issuer and stable subject identifier, Cmdexa account (tenant) IDRelay account identity storeAssociate your Google sign-in with your account and keep devices separated between accounts
Account sessionssigned session cookie containing the account ID, identity provider identifiers, account scope and expiry; temporary login-state cookieYour browser; pending login state is held temporarily in relay memoryKeep you signed in and protect the sign-in flow
Setup resume selectorThe opaque device ID for the setup attempt selected in one browser tab; no pairing code or device credentialThat tab's sessionStorage, with browser-managed retentionResume 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-inAn opaque random administrator cookie in the browser; its hash, opaque owner account ID and a cryptographic identity binding on the relayA protected owner-session store; never raw administrator cookie values on diskKeep the verified owner signed in without an application timeout; allow durable sign-out and reject sessions after owner identity/key changes
Task datatask 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, timingRelay task store, which can be persisted to a task history fileRun the task, show its progress, diagnose failures
Task outputbounded stdout and stderr, output-gap markersRelay task store, same limits as aboveReturn results to your AI client
Audit entriesstage, 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 storedBounded, in-memory audit log on the relayShow what happened and why an action was allowed or blocked
Tool historyredacted records of MCP tool callsOptional JSONL file on the relay, only if the operator enables itDebugging and support
Setup progressOpaque account/device IDs, allowlisted setup steps, server receipt times and fixed problem codes reported by the browserA bounded operational history on the relayIdentify 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 dataIP address and request metadata, which can appear in ordinary server logsRelay serverOperate and secure the service
Contact messagesyour email address and what you write to usThe operator's mailbox. Mail sent to @cmdexa.com addresses is forwarded through Cloudflare Email RoutingAnswer 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=user actions 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.com and email forwarding for @cmdexa.com addresses.
  • Email provider: messages sent to @cmdexa.com addresses 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.

Paweł Meller, Kaszubska 7, 81-813 Sopot, Poland · NIP 5833097492 · REGON 385413838kontakt@cmdexa.comPrivacyTerms