Privacy & Telemetry

What we collect, why, and how to turn it off.

XcodeBuildMCP uses Sentry for internal error monitoring. This helps track crashes and unexpected faults in the server code itself so the team can fix them. By default, the scope is strictly limited to XcodeBuildMCP's own runtime failures.

What's sent#

• Internal XcodeBuildMCP failures only: for example, daemon or MCP runtime faults, unexpected exceptions in server code.
• Internal operational logs only when explicitly marked for Sentry ({ sentry: true } in server code). Standard console logs are not auto-forwarded.
• Redacted event payloads: user home paths become /Users/<redacted>/..., request/user context is scrubbed before send.

What's never sent#

• User-domain errors: project build/test failures, invalid user config, missing scheme/destination, simulator/app-state errors are not sent.
• Tool inputs and outputs: tool arguments and return values are not captured by MCP wrapper telemetry (recordInputs: false, recordOutputs: false).
• Environment variables and system state: not attached as telemetry tags.
• Source code, build artifacts, binary content, certificates, provisioning profiles: none of these leave your machine.

Opting out#

Set the env var in your MCP client config:

{
  "env": {
    "XCODEBUILDMCP_SENTRY_DISABLED": "true"
  }
}

Or in your project config:

sentryDisabled: true

Or at the shell:

export XCODEBUILDMCP_SENTRY_DISABLED=true

Any of the three paths fully disables the SDK.

Why telemetry at all#

XcodeBuildMCP sits between your agent and Xcode's build system. A lot of edge cases (weird simulator states, odd Xcode versions, rare xcodebuild output shapes) only surface when something breaks in the wild. Narrow, opt-outable error telemetry is how the team catches and fixes those without asking every user to file a bug.

The telemetry scope was tightened in v2.1.0 to capture only internal runtime failures after #204.

Related#

• Configuration, for sentryDisabled in the config file
• Troubleshooting