Influxx sits in an unusual seat for a piece of software: it watches which files you touch, which agents you run, and what you write down while you work through a problem. That is a higher privacy bar than most SaaS products ever have to clear, because prompts, file paths, and project structure can be sensitive on their own, before anyone even attaches an identity to them. We did not answer that bar with a blanket promise to collect nothing — that claim does not hold up for a tool this complex, and we would rather not make one we cannot defend. Instead we built a narrower, auditable one: name exactly what is excluded, name exactly what is included, and default telemetry to on while making it trivial, instant, and fully explained when it is off.
Why This Tool Has a Higher Bar Than Most
Most telemetry conversations assume a fairly narrow surface: which pages you clicked, which button you pressed, maybe a browser and OS version. Influxx's surface is much wider by design, because the whole point of the product is to sit next to everything a developer does — thirty-plus coding-agent CLIs running in isolated git worktrees, notes written alongside them, all in one cockpit instead of scattered across separate apps. That means the raw material passing through Influxx on an ordinary day includes the content of prompts sent to an agent, the shape of a project's directory tree, the hostnames of remote hosts reached over SSH, and the branch names describing work that has not shipped yet. None of that needs a name or an email address attached to be sensitive. The content is the risk, independent of identity.
That is why we treat "we respect your privacy" as a sentence nobody should have to take on faith. A privacy-first telemetry policy for an AI developer tool has to be something a developer can check, not just something they are told. The rest of this piece is about how we tried to make that checkable — and why checkable, for us, meant opt-out by default rather than an opt-in wall that never quite gets tested.
The Case for Opt-Out (Without Making It a Trap)
The reflexive answer to "this tool sees sensitive material" is usually "then make telemetry opt-in." We considered that and rejected it, for a reason that has nothing to do with wanting more data and everything to do with what an opt-in checkbox actually accomplishes. Almost nobody clicks an opt-in box. The developers who do are a small, self-selected group, which means the resulting data is too skewed to be useful for the thing it is supposed to inform — the onboarding hints and feature tours that are meant to reflect how a typical user actually discovers the product, not how the unusually privacy-conscious sliver of users behaves. Worse, an opt-in checkbox mostly protects the company's legal position, not the developer's actual data, because it does nothing about what happens to the people who do click it if the underlying payload was never narrowed in the first place.
So we inverted the order of operations. Instead of gating collection behind a rarely-used checkbox and calling that privacy, we did the harder work first: deciding, category by category, what is even eligible to be collected, so that the dangerous classes of data are never in the payload regardless of anyone's setting. Only once that boundary held did we make the toggle default to on. Opt-out is defensible here specifically because flipping the default did not cost anyone anything they had not already been promised.
"An opt-in checkbox that almost nobody clicks isn't a privacy control, it's a liability shield. It protects our legal position, not the developer's actual data. We wanted the real protection to come from the boundary around what's collectible in the first place, so that flipping the default to on doesn't cost anyone anything they didn't already have."
— Ryan Chase, Security Engineer at ETAPX
That is the "not opt-in-forever" half of the argument. An opt-in-forever policy would let us claim caution while quietly never having to prove the boundary actually holds. Opt-out, paired with a payload narrowed before the toggle existed, forces the harder question to get answered up front.
One Function Decides: How Consent Actually Gets Resolved
Privacy policies fail in the gap between what a document says and what the code actually does, and that gap usually opens up when the same decision gets re-implemented in more than one place. Influxx resolves telemetry consent through a single, centralized precedence system rather than scattered checks throughout the codebase. Every part of the app that might send an event asks the same question and gets the answer from the same place, built from three inputs:
- Your stored preference: whatever you last set in the Settings and Privacy screen takes priority once it exists.
- Automated-environment detection: if the current run looks like a CI pipeline or another automated environment, telemetry is disabled regardless of any stored preference.
- Explicit environment-variable overrides: a value a user or their organization sets deliberately, which can force telemetry on or off independent of the interactive setting.
Funneling all three through one function is not a stylistic preference. It is what keeps the logic from drifting out of sync as the product grows — a new feature that fires its own telemetry event cannot quietly skip the CI check or misread the stored preference, because it never implements that check itself. It asks the one function that already got it right.
Why CI Runs Get Silenced Automatically
Automated environments get a hard no by default, and the reasoning is two-sided. First, nobody driving a CI pipeline affirmatively consented to being measured — there is no developer sitting at a keyboard making a choice, just a script executing on a schedule. Second, that traffic would corrupt the data even if it were consented to: thousands of headless, scripted runs behave nothing like a developer working through a real problem, and folding them into product-usage telemetry would distort exactly the signals the telemetry exists to produce. Auto-disabling CI is as much a data-integrity decision as a privacy one.
Telling You Why, Not Just Whether
Most privacy toggles are a single boolean: on or off. We modeled consent as a structured set of states instead, specifically so the Settings and Privacy screen can explain why telemetry is in its current state rather than presenting a flat switch with no context. "Off because you turned it off" and "off because this looks like a CI environment" and "off because an environment-variable override forced it" are different situations, and a developer trying to understand their own setup deserves to know which one applies rather than guessing from a single unlit switch.
This matters most when something looks wrong. If telemetry appears to be off and you never touched the setting, a flat boolean gives you nothing to go on — a structured state tells you immediately whether Influxx detected an automated environment, an override is in effect, or the preference really was set at some point and forgotten.
The Data That Never Leaves Your Machine
The sharpest version of this policy lives in the local feature-education system — the tours, tips, and onboarding hints that teach new users where things are. We put a hard, explicit rule on it: prompts, file paths, URLs, hostnames, and branch names are banned from ever appearing in any telemetry payload that system can produce, with no exception path for debugging convenience or a future feature. The record of which features you have already discovered — the state that lets Influxx avoid showing you the same tip twice — is kept entirely on your machine and is never uploaded, because there is no product reason for it to leave, only a convenience reason, and convenience is not a high enough bar for that decision.
- Never included, no exceptions: prompts, file paths, URLs, hostnames, and branch names cannot appear in a feature-education payload, regardless of the reason someone might want them there.
- Kept entirely local: your per-feature discovery state lives on your machine only and is never part of any upload.
- What does ship is generic and capped: a small, deliberately bounded set of events — a tour was shown, a tour was completed or dismissed — with a low-volume budget so the practice cannot quietly expand into broader usage surveillance over time.
"There's a version of this feature that would have been easier to support if we logged which file path a tour fired next to — it would have made a support ticket trivial to diagnose. We banned it anyway. The moment you let one path into a payload because it's convenient, you've established that paths are allowed, and the next exception is always easier to argue for than the first."
— Ryan Chase, Security Engineer at ETAPX
The budget cap matters as much as the ban. A single generic event is easy to justify in isolation; the risk is the tenth one, added a feature at a time, until the aggregate looks like usage surveillance nobody explicitly signed up for. Capping the volume up front means that drift has to be a deliberate decision, not an accumulation nobody noticed.
Naming Exactly What We Collect
Influxx documents, in plain language, what anonymous usage data it collects and exactly how to turn it off. That documentation is not a footnote — we treat it as connected to the same trust we are trying to build in Discord and the rest of our community, where the norm is answering questions in public rather than asserting a conclusion and hoping nobody checks. "We respect your privacy" is not a claim anyone can verify. A specific list of included and excluded categories is.
"I don't install a tool that touches every file in my repo based on a paragraph that says it cares about my privacy. I installed Influxx after reading the actual list of what ships home and what doesn't — prompts and file paths were on the excluded side, which is the only side that mattered to me before I pointed it at client work. That's a different kind of trust than a marketing page gives you."
— Priyanka Rao, DevOps lead at a health-data analytics startup, and Influxx user
That is the standard we are holding ourselves to going forward: every time the product's telemetry footprint changes, the documentation changes with it, in the same specific, checkable language rather than a broader promise that ages badly the first time someone reads the code instead of the marketing page.
What This Means for Teams Rolling Influxx Out
For an engineering lead evaluating Influxx for a team rather than themselves, the same environment-variable override that lets one developer force telemetry off also lets an organization set that policy centrally, instead of trusting each teammate to find the Settings and Privacy screen individually. Combined with automatic detection of CI and other automated environments, that means a fleet of build agents, CI runners, and contractor laptops can all inherit one deliberate answer rather than a patchwork of whatever each machine's default happened to be.
Frequently Asked Questions
Is telemetry on by default in Influxx?
Yes. General product-usage telemetry defaults to on, following the same opt-out model most developer tools use. We are comfortable with that default because the payload itself excludes prompts, file paths, URLs, hostnames, and branch names before consent is even considered. Turning it off is a single toggle in the Settings and Privacy screen, and it takes effect immediately.
What exactly does Influxx exclude from telemetry?
Prompts, file paths, URLs, hostnames, and branch names are hard-excluded from the feature-education system's payloads, and those same categories reflect the wider policy across the product: content and identifiers that could describe your code, your infrastructure, or your unreleased work are treated as off-limits regardless of whether telemetry is otherwise on.
How does Influxx detect CI environments, and why does that matter?
The consent-resolution logic checks whether the current run looks like a CI pipeline or another automated environment and disables telemetry automatically when it does. That traffic is not representative of real usage, and no one in an automated pipeline consented to being measured, so the safer and more honest default is silence.
Can my organization set a telemetry policy for the whole team?
Yes. Alongside the individual toggle in Settings and Privacy, Influxx honors explicit environment-variable overrides, so an engineering organization can set one policy centrally rather than relying on each developer to configure it individually on their own machine.
Why is telemetry opt-out instead of opt-in?
Because the harder privacy work already happened upstream, in deciding what is even eligible to be collected. An opt-in checkbox mostly protects against liability, not against risk, since almost nobody clicks it and the resulting data is too self-selected to usefully inform the product decisions it is meant to support. Once prompts, paths, and other sensitive categories were excluded by construction, defaulting to on stopped being the risky choice.
Where can I see exactly what Influxx collects?
The Settings and Privacy screen tells you the current state and why it is set that way — off because you turned it off, off because this looks like a CI environment, or on by default — and our public documentation lists the categories of anonymous usage data collected and how to opt out, so you can check the claim yourself instead of taking it on faith.
None of this makes Influxx's telemetry invisible, and we are not claiming it collects nothing — that would be an easy sentence to write and a hard one to stand behind. What we can stand behind is narrower: a precise list of what is excluded, a precise list of what is included, one function that decides the answer instead of a dozen scattered checks, and a default you can flip and verify in the time it takes to open a settings screen. That is what privacy-first has to mean for a tool that watches this much of your work — not a promise, but a boundary you can go check yourself.
