What “privacy-respecting” actually means in a developer tool

Concrete practices behind a privacy claim for tools that handle code and credentials.

Define the default

A privacy-respecting tool should be able to answer what leaves the machine, when it leaves, and why. For AdroitPad, local tools and Ollama inference are the default path; cloud model calls are opt-in and visible. Credentials and source files should not be sent to telemetry services simply because the editor opened them.

Transparency is a feature

No telemetry by default is a meaningful boundary when the tool handles proprietary code. Clear provider settings, explicit network actions, useful logs, and documentation make the boundary inspectable. Privacy is not a promise that nothing ever leaves the device; it is a system where the user can understand and control the exceptions.

Practical follow-up

A credible privacy boundary has a user-facing explanation and a technical control behind it. Provider settings, network logs, and export or deletion behavior should agree with the product’s promise rather than relying on a marketing label.

Review dependencies and update checks as part of the same policy. A tool can avoid telemetry while still pulling remote assets, sending crash data, or loading an extension with broader permissions than the core application.

Conclusion

Privacy becomes credible when the boundary is visible in both the interface and the implementation. The diagram moves from on-device defaults through an explicit user decision to opt-in cloud processing. That sequence gives users a way to reason about what leaves the machine and why. Telemetry, crash reporting, remote assets, and extensions must be reviewed alongside model requests. Documentation should match network behavior, credential handling, export, and deletion paths. A privacy-respecting tool is not one that makes absolute claims; it is one that makes exceptions understandable and controllable.