Privacy Policy

The short version

Kangentic is a desktop app that runs coding agents on your own machine. Your boards, tasks, and agent transcripts are stored on your device and are never uploaded to a Kangentic server.

Four things do leave your machine, and only these:

Separately, the coding agents Kangentic launches are third-party tools that talk to their own providers under your own accounts. That traffic is between you and them; Kangentic does not proxy it and never sees it. See Coding agents you run.

There is no Kangentic account, no login, no licence key, and nothing to sign up for. We do not sell data and we do not run advertising or cross-site tracking.

What stays on your device

The desktop app keeps its data in a local SQLite database in your operating system's application-data directory:

• %APPDATA%\kangentic\ on Windows
• ~/Library/Application Support/kangentic/ on macOS
• $XDG_CONFIG_HOME/kangentic/ on Linux, defaulting to ~/.config/kangentic/

That local data includes:

• Your projects, tasks, backlog items, and file or image attachments
• Agent session transcripts, which are a copy of the agent's terminal output with colour codes stripped
• The conversation-memory search index, when that feature is enabled
• Absolute paths to your projects and git worktrees
• Usage and cost figures for your own sessions

None of this is transmitted to Kangentic. It is also not encrypted at rest: the database is an ordinary file protected by your operating system's file permissions, so it is only as private as the machine and user account it sits on. Credentials you supply for optional integrations, such as an Asana or Azure DevOps personal access token, are encrypted using your operating system's secure storage (Keychain on macOS, DPAPI on Windows, kwallet or libsecret on Linux). On a system where that secure storage is unavailable, Kangentic warns and falls back to storing them unencrypted, in which case you must trust the local filesystem.

Kangentic does not store API keys for any AI provider. The agent CLIs use their own credentials, which they manage themselves.

Desktop app: usage analytics

The desktop app sends anonymous usage analytics through Aptabase, a privacy-focused analytics service for desktop apps. Analytics are enabled by default in official packaged builds and disabled in development builds.

Events are high-level counters: the app launching, closing, or hitting an error; a project being created, moved, or re-pointed; an agent session starting, finishing, or failing to start; a task reaching Done; an update being applied; the shape of a board when it is opened; and whether one of ten named features has been touched today. Their properties are counts, durations, exit codes, the agent and model identifier, permission mode, and token and cost totals. Error messages are stripped of file paths and truncated before being sent, and no stack traces are included in an analytics event.

Counts are counts, never content. A board snapshot sends how many columns a project has and a bucketed range for how many tasks, never their names. A feature event says a feature was used on a given day, never what it was used for. No task titles, descriptions, file paths, project names, code, or agent output is ever included in an analytics event.

Two things in this stream are worth stating plainly rather than filing under "anonymous":

• A stable installation identifier. One event per launch carries a clientId, a non-reversible digest derived from your operating system's machine identifier and your home directory path. It contains no raw machine identifier, path, or username, and it is not used to build a profile of how you use the app. It is, however, stable: it is the same value across app updates, and it stays the same if you uninstall and reinstall. It is unique per operating-system user account.
• Your IP address. As with any network request, the analytics request reveals your IP address to Aptabase, which resolves it to a country and then discards it. The country is retained; the address is not.

A stable identifier and an IP address are ordinarily personal data under the GDPR, so we describe them here rather than claiming the stream contains nothing personal at all.

Turning analytics off

Set the KANGENTIC_TELEMETRY environment variable to 0 or false. This disables every analytics event, including the installation identifier, and it disables error reporting too. To keep usage analytics and switch off only the error reports, set KANGENTIC_ERROR_REPORTING=0 instead. There is no in-app opt-out: the Privacy tab is informational only, so the environment variables are the control.

To make it permanent, add it to your shell profile or your system environment variables. For the full event table and per-platform instructions, see Privacy & Analytics in the documentation.

Desktop app: update checks

On every platform the app checks GitHub Releases for a new version shortly after launch and then every four hours. Each check reveals your IP address, the app version, and your platform to GitHub, in the same way visiting any web page would. Updates are downloaded only after a newer version is found, and installed when you quit the app.

Linux is the exception to that last step: a packaged Linux build checks and downloads like the others, but installing needs your package manager, so the update stays staged until you choose Restart to update. See Auto-Updates for details.

Desktop app: crash and error reports

When the desktop app crashes or hits an unexpected error, it sends an error report to Sentry, the same third-party error-monitoring service the mobile app uses, so the fault can be found and fixed. This is diagnostics, not analytics: it is about the app breaking, not about you using it. Electron's built-in crash reporter is never enabled, so no crash dumps or minidumps are uploaded.

An error report contains the error type, its message, the stack trace, the app version, and the platform. Before it leaves your machine, the Sentry SDK rewrites every stack-frame path and URL relative to the application root, so your home directory does not travel with the trace. Personally identifiable data collection is switched off in the SDK, Sentry's own server-side scrubbing is on, and performance tracing and session replay are never enabled.

The report carries the same anonymous clientId described above as its user identifier, so an issue can be counted as "installs affected" rather than left as an unbounded number of reports. It is the same non-reversible digest, with the same properties and the same opt-outs, and it is not used to build a profile of how you use the app.

The anonymous app_error analytics event described above still fires alongside it, and it is deliberately narrower: it carries a sanitised message and no stack trace. A user-interface error adds three fields that say where it happened: which of the three reporters caught it, the failing panel's label, and a trail of React component names. The raw component stack is never sent to Aptabase, because a production stack frame embeds a file:// URL containing your home directory. Kangentic reduces it to component names before anything leaves the process, and a name cannot carry a path.

Set KANGENTIC_ERROR_REPORTING to 0 or false to switch error reporting off while leaving usage analytics on. KANGENTIC_TELEMETRY=0 switches off both.

Mobile app: crash reports

When the mobile app crashes or hits an unexpected error, official builds send a crash report to Sentry, a third-party error-monitoring service, so the fault can be found and fixed. This is diagnostics, not analytics: it is about the app breaking, not about you using it.

A crash report contains the technical details of the failure, and nothing about what you were doing in the app:

• the error type, message, and the stack trace showing where in the app's code it happened
• the app version, plus the standard device diagnostics that accompany any crash report: your device model, its operating system version, and the ordinary technical state alongside them (things like battery level, free memory and storage, screen size and orientation, and device timezone)
• when the crash is caught by the operating system rather than by the app's own code, a short trail of technical state changes leading up to it: the app moving to the foreground or background, battery level and charging state, the screen turning on or off, and network conditions such as connection type, signal strength, and approximate data throughput. These describe the app's and device's technical state, never yours

It deliberately does not contain your session content. No screenshots, no screen recording, no on-screen text, no keystrokes, no console output, no network request details, no transcripts, terminal output, code or diffs, no notification content, and no pairing or encryption keys. Those are not stripped out afterwards; they are never collected in the first place.

There is no account to attach an identifier to, and the app sends no account, email, username, or user profile with a crash report, and does not use crash data to build any picture of how you use the app. A crash caught by the operating system, rather than by the app's own code, does carry one identifier: a random ID generated on your device by the crash-reporting software itself, not by Kangentic. It resets if you uninstall and reinstall the app, it is not your device's hardware ID or an advertising ID, and it is not used to identify you or to link a crash report to any other data.

Builds you compile yourself from the open-source repository have crash reporting switched off entirely and send nothing.

Mobile app: camera, microphone, notifications

• Camera. Used only to scan the QR code the desktop app displays during pairing. Camera frames are processed on-device to read the code and are never stored or transmitted.
• Microphone. Used only when you tap dictation in the message composer, to turn speech into text via your device's built-in speech recognition. Audio is not stored or transmitted by Kangentic. Your device's speech engine may itself send audio to its own provider, for example Google or Apple, to produce the transcript; that processing is governed by your device provider's privacy policy, not this one.
• Notifications. The app registers for push notifications so the desktop can alert you to activity in your agent sessions. Push payloads are end-to-end encrypted ciphertext plus a generic placeholder; Kangentic's servers and any relay never see the plaintext content, and decryption happens only on your device.

Pairing your phone, and the relay

Pairing a phone to a desktop links them directly. Because the desktop usually sits behind a home or office router, both devices connect outward to a small relay server that forwards bytes between them.

Everything that crosses the relay is end-to-end encrypted between your phone and your desktop. The relay forwards opaque ciphertext and has no ability to decrypt it: it holds no keys, and the encryption is negotiated directly between your two devices inside the tunnel it forwards. Session content is never written to a Kangentic server or to any third-party service.

Being blind to content is not the same as being invisible, so here is what a relay operator can still observe, including Kangentic when you use the hosted one:

• Source and destination IP addresses of both peers.
• Connection timing: when each peer connects, disconnects, and reconnects.
• Frame sizes and frequency, which is traffic shape rather than content.
• The pairing graph: which connections were rendezvoused together.

This is inherent to operating any relay and is not specific to Kangentic's. The relay writes nothing to disk, and its logs contain no connection identifiers and no client IP addresses. On the hosted instance, TLS is terminated by Cloudflare, which therefore sees the connection URL and the routing identifier it carries. You can remove Kangentic from this picture entirely by running your own relay: it is open-source and self-hostable, and pointing your desktop at it is a single setting. See The Hosted Relay and Self-Hosting the Relay.

Push notifications are delivered through Expo's push service and the platform push networks, which are Firebase Cloud Messaging on Android and APNs on iOS. Those services see your device's push token and delivery timing. They receive only the encrypted payload and a generic placeholder title, never the decrypted content.

On the phone, pairing keys and trust anchors are stored in your device's hardware-backed secure storage: the Keychain on iOS, the Android Keystore on Android. Session content lives only in memory on your device while the app is running.

Coding agents you run

Kangentic launches coding-agent command-line tools that you have already installed, using the credentials you have already configured for them. Supported agents are Claude Code, Codex, Gemini, Cursor CLI, GitHub Copilot CLI, Grok Build, Antigravity CLI, OpenCode, Aider, Qwen Code, Kimi Code, Factory Droid, Warp (Oz CLI), and Ollama.

With the exception of Ollama, which runs models locally, these tools send your prompts, your code, and their tool output to their own providers, under your own account with that provider. That is what they are for. Kangentic does not proxy those requests, does not hold the API keys, and does not see the traffic. What you send to each provider is governed by that provider's own privacy policy and your agreement with them.

Kangentic does read and store the resulting session transcripts locally, as described in What stays on your device, and it writes task titles and descriptions into the agent's terminal when you start or hand off a session.

Optional features that use the network

These are off unless you turn them on or connect them:

• Cloud dictation. Voice dictation transcribes on-device by default and needs no network access. If you explicitly configure a cloud transcription endpoint, the recorded audio clip is uploaded to the URL you specify, using the API key you supply. The live preview still runs on-device. This is off by default and fails closed when no endpoint is configured.
• Speech and embedding model downloads. Enabling dictation or semantic conversation search downloads model weights once from Hugging Face. After that the models run offline. Indexing and searching your conversations is fully local and never leaves your machine.
• Backlog import. Connecting GitHub Issues, GitHub Projects, Azure DevOps, or Asana contacts those services using credentials you provide, to read the issues you ask it to import. For GitHub this is delegated to the gh command-line tool, so Kangentic never handles your GitHub token.
• Git operations. Fetching and pushing contacts whichever git remotes your repositories are configured with.
• The embedded browser. Pages you or an agent navigate to in the built-in browser pane are ordinary web requests to those sites.

This website

kangentic.com uses Umami for basic traffic analytics: page views, referrers, coarse device and country information, and a count of clicks on the "Star on GitHub" links. Umami is cookieless and does not track visitors across other websites, so there is no advertising profile and no cross-site identifier.

The site is hosted on Cloudflare Pages. As with any web host, Cloudflare processes the network requests needed to serve pages to you, including your IP address.

What Kangentic never does

• No account. There is no sign-up, no login, no licence key, and no entitlement system, so there is no account data to collect.
• No selling of data. We do not sell or rent personal data, and we do not share it with data brokers.
• No advertising or cross-site tracking. No ad networks, no tracking pixels, no advertising identifiers.
• No reading of your content. Kangentic operates no service that can read your tasks, code, or agent transcripts. The relay carries ciphertext it cannot decrypt, and crash reports and analytics carry no session content.

Retention

• Local data stays on your device until you delete it. Removing a project from Kangentic or deleting the application-data directory removes it.
• Crash and error reports, desktop and mobile, are retained by Sentry under the organisation's plan retention, 30 days on the current plan, and then deleted.
• Desktop analytics are retained by Aptabase under their own retention policy. Events carry no account identifier.
• Relay traffic is not stored. The relay forwards bytes between two live connections and keeps no database or message history.

Your choices

Because there is no account, most privacy controls are things you can do directly rather than requests you have to make of us:

• Turn off all desktop telemetry with KANGENTIC_TELEMETRY=0, or just the error reports with KANGENTIC_ERROR_REPORTING=0.
• Delete your local data by removing the application-data directory listed above.
• Avoid Kangentic's relay entirely by self-hosting your own, or by not pairing a phone at all.
• Leave cloud dictation unconfigured, which is the default, to keep all voice transcription on-device.
• Build from source to get a mobile app with crash reporting compiled out.

We hold no account, email address, or user profile, so there is no per-user record for us to look up, export, or delete on request. Crash reports carry no identifier that can be traced back to a person and expire on their own within 30 days. If you have a question about data you believe relates to you, contact us using the details below and we will help as far as the data allows.

Changes to this policy

If this policy changes, the date at the top of this page will change and the revised policy will be published at this same URL.

Contact

Kangentic is a product of VORPAHL LLC.

Questions about this policy can be sent to hello@kangentic.com or raised on the project's GitHub repository . For anything involving logs or private project details, use support@kangentic.com instead.

To report a security vulnerability, please use hello@kangentic.com with "SECURITY" in the subject line, or GitHub's private vulnerability reporting.

---

For a technical breakdown of every desktop analytics event and its properties, see Privacy & Analytics in the documentation.