Glider products run locally. Your code, prompts, project files, and local runtime evidence are never sent to Glider servers.
The MCP server you configure analyzes files or artifacts in your workspace and returns results to your MCP client. The products send anonymous usage telemetry (versions, OS, tool names, error categories) so we can improve them; this is documented in full on the What we collect page and can be turned off.
Glider product tooling runs on your machine. Requests are handled locally, and project files remain in your workspace.
To learn how the products are actually used — so we can fix the right bugs and remove tools nobody uses — the MCP servers send a small amount of anonymous usage data: a random install id (no machine fingerprinting), product and version, OS and architecture, runtime version, tool names with a duration bucket and success/error outcome, error categories (exception type names only, never messages), and coarse workspace shape counts. scout also reports which search route answered a search. These are fixed category names such as the target, the match mode, and the tier. It never reports what you searched for, or how many results it found. A server also reports bucketed health numbers when its own resource use reaches a level that indicates a leak. These are handles, memory, and uptime. They tell us whether a fix for a known leak works. Country is derived at our edge from the network request and the IP address is never stored.
It never includes your source code, file paths, file or symbol names, prompts, command arguments, or raw error messages.
Telemetry is on by default and easy to turn off: run the server with the --no-telemetry flag (or set DO_NOT_TRACK=1 in the environment that launches it). The full field-by-field list and opt-out details are on the What we collect page at /privacy/telemetry.
A send_feedback tool lets an agent report a missing capability or a poor result. Glider ships it from version 10.3.0; Scout, TGlider, and GliderTrace do not have it yet. It is the one channel that carries text you or your agent wrote. The tool description asks the agent to use it when it meets a gap and to tell you what it sent. Whether a tool runs without asking you is a setting in your MCP client, not something our server can enforce.
A report carries a category and a message of at most 500 characters. It names the tool it is about, your coding agent, and your model. It also carries the same product, version, and platform facts as telemetry, plus a report id, your install id, and your session id.
The report becomes a public issue in our support repository on GitHub, and the tool returns the link to you. That issue carries only the report id. Your install id and session id stay out of it. A message that reads like source code, a file path, a secret, or a stack trace is rejected with a reason. The agent then describes the problem in general terms instead.
Turn it off with GLIDER_FEEDBACK=0. The --no-telemetry flag and DO_NOT_TRACK=1 also disable it. The full field list is on the What we collect page at /privacy/telemetry.
The public website uses Google Analytics to understand aggregate page usage. This analytics does not include your source code, prompts, diagnostics, project files, or local MCP traffic.
Glider does not retain your code or your work on Glider servers. Any files, logs, artifacts, or MCP client transcripts live in your local environment or in the client you choose.
Two things are kept, and both are listed above. Anonymous telemetry events are held by our analytics provider. A feedback report you choose to send is stored in our database until 30 days after its public issue exists, and the issue stays until we close and archive it.