Desktop Commander MCP Telemetry: What Data Is Collected and How to Opt Out

Desktop Commander MCP collects anonymous usage metrics including tool invocations and system information, but you can completely disable telemetry via the telemetryEnabled config setting or the DISABLE_TELEMETRY environment variable.

The wonderwhy-er/DesktopCommanderMCP repository includes a built-in telemetry system that reports anonymous usage data to help improve the tool. According to the source code, this system captures specific execution metrics while providing multiple opt-out mechanisms for privacy-conscious users.

What Telemetry Data Does Desktop Commander MCP Collect?

The telemetry payload is assembled in src/utils/capture.ts and sent to https://telemetry.desktopcommander.app/mp/collect. The system captures the following anonymous data fields:

Anonymous Identifiers

• clientId: A persistent, randomly-generated UUID that identifies the installation without linking to personal data.
• sessionId: An optional short-lived identifier that links events belonging to the same interactive session.

Tool Execution Metrics

• toolName: The specific tool that was invoked (e.g., file operations, search commands).
• toolArgs: The arguments passed to the tool (note: file contents and sensitive data are not transmitted).
• durationMs: Execution time of the tool in milliseconds.
• success/error: Boolean indicating completion status, plus sanitized error messages if failures occur.
• timestamp: ISO-8601 timestamp of when the event was generated.

System Information

• appVersion: The current version from package.json.
• platform/OS info: Operating system name, version, and CPU architecture obtained from src/utils/system-info.ts.

As implemented in wonderwhy-er/DesktopCommanderMCP, no file contents, environment variables, passwords, or personally identifiable information are ever transmitted.

How to Disable Desktop Commander MCP Telemetry

The codebase provides two distinct methods to disable data collection, both checked in src/utils/capture.ts before any network request is made.

Method 1: Configuration File (Persistent)

The primary opt-out mechanism uses the user-editable JSON configuration file managed by src/config-manager.ts. The default value is defined at line 173 with telemetryEnabled: true, implementing an opt-out approach.

To disable telemetry permanently, set telemetryEnabled to false in your config.json:

{
  "telemetryEnabled": false
}

The capture logic checks this flag at lines 107-110 in src/utils/capture.ts, returning early if telemetry is disabled before constructing any payload.

Method 2: Environment Variable (Temporary)

For temporary disabling or CI/CD environments, set the DISABLE_TELEMETRY environment variable. As noted in the inline comments at lines 44-46 of src/utils/capture.ts, this acts as a "hard kill-switch" that overrides the persisted config:

DISABLE_TELEMETRY=1 desktop-commander <command>

When this variable is present, the capture module exits immediately, skipping both payload construction and network transmission.

Code Examples for Opting Out

Using the CLI

The recommended approach for end users is the built-in configuration command:

# Check current telemetry status

desktop-commander config get telemetryEnabled

# Disable telemetry permanently

desktop-commander config set telemetryEnabled false

These commands update config.json via the configManager API defined in src/config-manager.ts.

Programmatic Configuration

Developers integrating with Desktop Commander MCP can disable telemetry programmatically:

import { configManager } from './src/config-manager';

// Disable telemetry for the current process
await configManager.updateConfig({ telemetryEnabled: false });

This approach uses the same configuration persistence layer that the CLI and runtime respect.

Environment Variable in Scripts

For automation scripts or one-time invocations:

#!/bin/bash
export DISABLE_TELEMETRY=1
desktop-commander execute-tool --name "search_files"

This method is particularly useful in track-installation.js and uninstall-claude-server.js workflows where you want to suppress installation events.

Summary

• Data Collection: Desktop Commander MCP captures anonymous tool usage metrics (tool names, execution duration, success rates) and system information (OS, version, architecture) via src/utils/capture.ts.
• Endpoint: Data is sent to https://telemetry.desktopcommander.app/mp/collect (with a fallback URL).
• Opt-Out Methods: Users can disable telemetry by setting telemetryEnabled: false in config.json (persistent) or setting DISABLE_TELEMETRY=1 (temporary).
• Implementation: The config-manager.ts handles persistence, while capture.ts lines 107-110 enforce the check before transmission.
• Scope: No personal data, file contents, or credentials are collected.

Frequently Asked Questions

Is Desktop Commander MCP telemetry data anonymous?

Yes. According to the source code in src/utils/capture.ts, the system generates a random clientId UUID that is not correlated with personal data. No user names, file contents, environment variables, or passwords are included in the payload sent to telemetry.desktopcommander.app.

Where is the telemetry configuration stored?

The configuration is stored in a config.json file located in the user's configuration directory. The exact path is managed by src/config-manager.ts, which defines the default telemetryEnabled: true value at line 173. You can modify this file directly or use the CLI commands to update settings safely.

Does disabling telemetry affect application functionality?

No. The telemetry system in src/utils/capture.ts is designed to fail silently and return early when disabled. Whether you use the telemetryEnabled config flag or the DISABLE_TELEMETRY environment variable, all core file operations, tool executions, and MCP server functionality remain fully operational without the analytics transmission.

What endpoint receives the telemetry data?

By default, Desktop Commander MCP sends telemetry to https://telemetry.desktopcommander.app/mp/collect, with a fallback URL configured in src/utils/capture.ts. The code constructs the payload around lines 254-262 and handles the HTTP POST request asynchronously to avoid blocking tool execution.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}