Privacy Policy

CouchCode is an independent software project operated from Estonia. In this policy, “CouchCode”, “we”, “us”, and “our” refer to that project. We built CouchCode so you can drive AI coding agents on your own machine from your phone — and we designed it so that, by default, your code, prompts, terminal output, and credentials live on your own devices, not on ours.

This policy explains, in plain terms, what data exists, where it lives, what passes through our infrastructure, and what we can and cannot see. We’ve tried to describe the product accurately and specifically rather than as a generic template. If something here is unclear, email us.

1. Who Operates CouchCode

CouchCode is an independent software project operated from Estonia. It is not a venture-backed company, and there is no large team behind it. For any privacy question or request, contact us.

2. What This Policy Covers

CouchCode has several parts, and they handle data very differently:

• The website (couchcode.io) — this marketing site.
• The mobile app — the iOS and Android client you install on your phone.
• The daemon — the open-source program you run on your own computer, which talks to your coding agent.
• The relay — an optional hosted service that forwards traffic between your phone and your daemon when they aren’t on the same network.

This policy covers all of them. Where a given part behaves differently, we say so explicitly.

3. How CouchCode Works (and Why That Matters for Privacy)

Your phone (the app) sends instructions to a daemon running on your own computer. The daemon hands that work to a coding agent (such as opencode, Codex, Kimi, or Claude Agent) that is already installed on your machine, and streams the results back to your phone.

There is no CouchCode account and no central database of your projects. The daemon runs on your hardware; the agent runs on your hardware; your model-provider API keys stay on your hardware. The hosted relay forwards traffic between your devices — and with end-to-end encryption on, it forwards data it cannot read. The mobile app also uses a small set of Google Firebase services (for optional push notifications, crash diagnostics, and operational configuration), described in the sections below; these handle limited technical data and, by design, not the content of your sessions.

4. Information CouchCode Processes

CouchCode does not ask you to create an account, and does not collect your name, email address, or contact details to use the app. CouchCode does not currently require an account for LAN pairing.

The data that exists falls into a few buckets:

• Content you create — prompts you type or dictate, commands you run, code, files, and the agent’s output. This is the working content of a session. It is stored on your devices; in Relay mode it may pass transiently through the relay as described below (the relay keeps no message history, and what it can see depends on end-to-end encryption).
• Device credentials and keys — secrets that let your phone and daemon trust each other (see the Pairing section).
• Connection metadata — the technical details needed to route traffic when you use the relay (see the Relay section).
• Push, diagnostic, and configuration data — when those features are present in the mobile app, a limited set of technical identifiers and diagnostics is processed by Google Firebase to deliver notifications, report crashes, and fetch operational settings (see the Push Notifications, Diagnostics, and Remote Configuration sections).

Where each of these lives depends on whether you’re running in Local mode or Relay mode, whether end-to-end encryption is on, and which optional features you use.

5. Local (LAN) Mode

When your phone and your computer are on the same network, you can pair them directly. In this mode your session traffic and content move directly between your phone and your daemon over your local network, and do not pass through the CouchCode relay or any other CouchCode-hosted infrastructure. Push notifications are not used for Local-mode sessions, and your Local-mode session content is never sent to Firebase. The mobile app may still contact Firebase separately for crash diagnostics and operational configuration (described below) — but that is limited app-level technical data, not your session content.

6. Relay Mode

When your phone and computer aren’t on the same network, you can route through the hosted relay at relay.couchcode.io. The relay’s job is to forward bytes between your phone and your daemon — nothing more. It does not store your session content or message history.

To do that forwarding, the relay necessarily handles some connection metadata: the IP addresses of the connecting devices, the routing identifiers for your daemon and client, timestamps, connection state (connect/disconnect), and the size of messages it passes. This metadata is processed in memory to route the connection and is written to standard operational logs (journald) for reliability and abuse prevention. Those logs are transient and are not exported to any analytics product. The relay never logs pairing codes, device credentials, or message content.

Whether the relay can see your actual content depends entirely on end-to-end encryption — described next.

7. End-to-End Encryption

End-to-end encryption (E2EE) is optional and off by default. You turn it on when you pair, and it applies per pairing.

• With E2EE on: your phone and daemon exchange and pin keys at pairing (X25519 key agreement, ChaCha20-Poly1305 for the messages). From then on the relay only ever forwards ciphertext. It cannot read your prompts, commands, code, terminal output, agent responses, or credentials. A key mismatch is refused outright, so there’s no silent man-in-the-middle.
• With E2EE off: relay traffic still travels over TLS in transit, but the relay forwards your content in a form it could technically read while routing it. We don’t store that content, but if you want a guarantee that nobody at the relay could read it, turn E2EE on — or use Local mode, which skips the relay entirely.

E2EE protects the content of your messages between your phone and your daemon. It does not hide connection metadata from the relay — IP addresses, routing identifiers, timestamps, connection state, and message sizes are still visible to the relay because they’re needed to deliver the traffic. It also does not cover push notifications, which travel separately through Google’s and Apple’s push infrastructure (see Push Notifications).

8. Pairing and Device Credentials

Pairing is how your phone earns the right to control your daemon. When you pair, the app scans a QR code (or follows a deep link) that contains a short-lived, single-use pairing code, the connection mode, and the address to reach your daemon. The QR code does not contain your long-term credential or your encryption secret key.

Pairing codes are six digits, generated with a cryptographically secure random number generator, valid for two minutes, limited to a few attempts, and burned after a single successful use. They are never written to logs.

Once paired, the app holds a device credential that authenticates it to the daemon, and (if E2EE is on) an encryption secret key. On the phone these are kept in protected operating-system storage — the iOS Keychain, and on Android an encrypted store whose keys are managed through the Android Keystore — rather than ordinary, unencrypted app storage. The daemon, on your computer, stores only a salted hash (verifier) of each device credential, never the credential itself, so a paired device can be individually revoked.

9. Push Notifications

Push notifications are optional. They let CouchCode tell you when your agent needs you — for example, when it’s waiting on a permission decision or has hit an error — while the app is in the background. Push notifications are available only for Relay-mode connections; Local-mode sessions do not use the CouchCode relay push pipeline.

When you enable notifications, the mobile app registers your device with Firebase Cloud Messaging (FCM), Google’s push service. Google processes a push registration token and the related technical identifiers needed to deliver messages to your device (including a Firebase installation identifier). On Android, FCM delivers the notification directly; on iOS, FCM routes the notification through the Apple Push Notification service (APNs). The registration token is used only to deliver CouchCode notifications.

The notification itself is deliberately content-free. Its visible text is fixed, generic copy (for example, “An agent needs your approval”), and the only data it carries is a couple of technical identifiers — a device identifier and a session identifier — used to open the app to the right session. A push notification does not contain your code, prompts, terminal input or output, file contents or paths, command text, agent output, model-provider API keys, device credentials, pairing codes, or encryption keys.

Because push notifications travel through Google’s (and, on iOS, Apple’s) push infrastructure, they are not covered by CouchCode’s relay end-to-end encryption, and the delivery metadata needed to route them is visible to those push providers as part of normal delivery. You can turn notifications off at any time in your operating system’s settings. A registration token may be rotated or invalidated by the platform; CouchCode removes or disassociates a stored token when its unregister path runs, and invalid tokens are removed when the push service reports them unusable.

10. Diagnostics and Crash Reporting

The mobile app uses Firebase Crashlytics (Google) to find and fix crashes and stability problems. When the app crashes, encounters an Android “application not responding” (ANR) condition, or records a non-fatal error, Crashlytics may send a diagnostic report to Google that can include the app version and build, operating-system and device information, timestamps, stack traces and related technical state at the time of the problem, and a pseudonymous app-installation identifier.

This is technical diagnostic data, not behavioral tracking, and it is used only to keep the app reliable. CouchCode is designed not to attach session content or credentials to diagnostic reports — that means we don’t intentionally include your prompts, source code, file contents, diffs, terminal input or output, command arguments, model-provider API keys, device credentials, pairing codes, or encryption keys. Low-level crash diagnostics may include exception messages, stack traces, logs, ANR information, and technical state generated by the platform. CouchCode therefore avoids placing session content or secrets in diagnostic messages, custom logs, or Crashlytics metadata.

11. Remote Configuration

The mobile app uses Firebase Remote Config (Google) for operational configuration. The app periodically fetches configuration values from Firebase that can control things like feature availability, staged enablement of selected features, maintenance messaging, minimum-supported-app-version checks, relay endpoint or connection settings, and operational safety switches (“kill switches”).

To fetch and apply configuration, broad technical information is sent to Google — such as the app identifier, app version and build, platform and operating system, device locale, a Firebase installation identifier, and fetch timestamps and status. Remote Config is used only for operational and feature-safety configuration. It is not used for advertising, behavioral targeting, user profiling, experimentation based on sensitive behavior, or account-based segmentation, and it does not store your session content. If Remote Config is unavailable, the app falls back to safe local defaults.

12. App Lock and Biometrics

You can optionally lock the app behind Face ID, Touch ID, or a fingerprint, with a PIN fallback. This is entirely on-device. Biometric matching is performed by your operating system; the app only ever receives a yes/no result and never sees or stores any biometric data. If you set a PIN, the app stores only a salted hash of it in secure storage — never the PIN itself — so it can verify your entry without being able to recover the PIN.

13. Coding Agents, Model Providers, and API Keys

CouchCode does not run AI models and does not resell model access. Your coding agent runs on your own machine and talks to whatever model provider you’ve configured it with, using API keys stored in that agent’s own configuration on your computer. CouchCode never sees those keys, never proxies your model traffic, and adds no markup — there is no CouchCode server in that path to send them to.

14. Voice Input

Voice input is optional, and how it’s handled depends on your setup:

• Operating-system speech recognition by default: by default, CouchCode uses the speech-recognition service provided by your operating system. Depending on your device, OS, language, and settings, recognition may happen on-device or may be processed by the operating-system provider under its own privacy terms. The transcript is shown to you as editable text before anything is sent to your agent — CouchCode does not auto-send it.
• Optional cloud transcription: if (and only if) you choose to enter your own OpenAI API key in the app, voice audio is sent to OpenAI’s transcription service (api.openai.com) using your key, and OpenAI’s handling of that audio is governed by OpenAI’s terms and privacy policy. If you don’t provide a key, no audio is sent to OpenAI. Your OpenAI key is stored on your phone and is used only to make that request.

15. Remote Terminal and Session Content

CouchCode includes a remote terminal so you can run commands on your computer from your phone. Terminal input and output are session content: they travel between your phone and your daemon the same way other content does (directly in Local mode, or via the relay in Relay mode, encrypted end-to-end if you’ve enabled it).

Session history is stored locally by the daemon on your own computer (under your home directory), so you can reconnect and catch up after a dropped connection. This history stays on your machine — it is not uploaded to CouchCode, and the relay keeps no copy of it. Because it lives on your computer, it remains there until you delete it; you are in control of that data.

16. Website Data, Cookies, and Analytics

The CouchCode website is a static site. It runs no analytics, no advertising, no tracking pixels, and sets no tracking or marketing cookies. We don’t use Google Analytics or any comparable product, and we don’t build profiles of visitors. (The Firebase services described above are used by the mobile app, not by the website.)

The site is served through a content delivery network (Cloudflare, via our host). That CDN may set a single essential security cookie (for example, to tell humans from bots) and keeps basic server/CDN request logs (such as IP address and request time) for security and reliability. That’s the extent of website data collection.

17. Third-Party Providers

CouchCode relies on a small number of service providers, used only to run the service — not to profile you:

• DigitalOcean — hosts the relay and the website.
• Cloudflare (via our host) — content delivery and edge security for the website.
• Google / Firebase — used by the mobile app for:
  • Firebase Cloud Messaging — delivers optional push notifications; processes a push registration token, an app-installation/device identifier, and the delivery-related technical information required to route notifications (on iOS, via Apple’s APNs).
  • Firebase Crashlytics — crash, ANR, and non-fatal error diagnostics (app/build and device/OS information, timestamps, stack traces, and a pseudonymous installation identifier).
  • Firebase Remote Config — operational configuration and feature-safety controls; on each fetch it sends broad technical app/device information (such as app identifier, version, platform, locale, an installation identifier, and fetch status).
• OpenAI — only if you opt into cloud voice transcription with your own key (see Voice Input).

The agents and model providers you connect to are chosen and configured by you, on your own machine, and are governed by their own terms. CouchCode does not use Firebase Analytics, Firebase Performance Monitoring, Firebase Auth, Firestore, Realtime Database, Firebase In-App Messaging, any advertising SDKs, or any behavioral or cross-app tracking. The daemon and the relay use no third-party analytics or crash-reporting SDKs at all.

18. How Information Is Used

The limited data CouchCode processes is used only to:

• Route traffic between your phone and your daemon (relay connection metadata).
• Authenticate your paired device to your daemon (device credentials).
• Deliver the push notifications you’ve enabled (Firebase Cloud Messaging / APNs).
• Diagnose crashes and stability problems so we can fix them (Crashlytics).
• Fetch and apply operational configuration and safety switches (Remote Config).
• Keep the service reliable and protect it against abuse (transient operational logs).

We do not use your content for advertising, we do not sell your data, and we do not use your code, prompts, terminal content, or agent output to train any model.

19. Legal Bases for Processing

Where the GDPR or similar data-protection laws apply, CouchCode relies on the following legal bases:

• Performance of a contract — to provide the app and the features you choose to use, including pairing your devices, authenticating them, routing Relay-mode connections, delivering the Relay-mode notifications you’ve enabled, and applying the operational configuration needed for the service to work.
• Legitimate interests — to operate, secure, maintain, debug, and improve CouchCode; prevent abuse; diagnose crashes, ANRs, and non-fatal errors; and keep limited operational logs. These interests are running a secure and reliable developer tool, protecting the relay and its users from abuse, and identifying and fixing technical failures — and they are balanced against the limited, mostly technical nature of the data processed.
• Consent — only where an optional permission or optional feature legally requires it, such as notification permission, microphone permission, or optional cloud transcription. You can withdraw permission or disable the feature at any time through the app or your operating-system settings.
• Legal obligation — where processing or disclosure is necessary to comply with applicable law.

CouchCode does not rely on consent where processing is necessary to provide a feature you requested or to secure and operate the service.

20. Data Sharing

We don’t sell your personal information, and we don’t share your content with third parties for their own purposes. Data is handled only by the service providers listed above, solely to operate the service. In particular, Google/Firebase receives the push-delivery, diagnostic, and configuration-fetch data described above so that those features can work — this is service-provider processing to deliver functionality you’ve used, not a sale and not advertising. We may also disclose information if we are legally required to do so; by design, the relay holds little (transient connection metadata) and no session content, so there is little to disclose there.

21. Data Retention and Deletion

• Session content and history live on your own devices. The daemon’s session history stays on your computer until you delete it; you control it directly.
• Credentials and encryption keys on your phone stay in protected device storage until they’re removed by the app, invalidated by unpairing or revocation, or cleared by the operating system. On some platforms these protected-storage items can persist across an app reinstall, so revoking the device on the daemon is the reliable way to cut off access — a reinstalled app cannot regain control with a credential the daemon has already revoked.
• Push registration tokens are kept only while needed to deliver the notifications you’ve enabled. They may be rotated by the platform; invalid tokens are removed when the push service reports them unusable; and a stored token is removed or disassociated when CouchCode’s unregister path runs.
• Firebase delivery, diagnostic, installation, and configuration-fetch data is retained according to CouchCode’s configured Firebase settings and Google’s applicable service handling.
• Relay metadata is processed in memory for the life of a connection. Operational logs are transient and rotate as part of normal system operation; they are not archived into any long-term analytics store.
• Website/CDN logs are retained only briefly for security and reliability, per our providers’ standard handling.

Because most of your data never leaves your own devices, the most direct way to remove it is to delete the session history on your computer and revoke or unpair the device on the daemon. Uninstalling the app removes its data on Android; on iOS, revoking the device on the daemon is what reliably invalidates access, since some protected-storage items can outlive an uninstall. To request deletion of any server-associated data, such as a stored push token, email us.

22. Security

Security is the point of the product, not an afterthought. The daemon is open source so you can read exactly what it does. Pairing requires a short-lived, single-use, rate-limited code. Device credentials are stored only as salted hashes on the daemon, and in protected operating-system storage (the iOS Keychain, or Android Keystore-managed encryption) on the phone. End-to-end encryption (X25519 + ChaCha20-Poly1305) is available so that even our relay can only forward ciphertext, and a key mismatch is rejected rather than silently accepted.

No system is perfectly secure, and you play a role too: keep your devices and their locks in your control, and revoke any device you no longer trust.

23. Your Rights

Depending on where you live, you may have rights to access, correct, delete, export, or object to the processing of your personal data, and to withdraw consent where processing relies on it. Because CouchCode holds little — no accounts, and otherwise only limited technical data (relay connection metadata, and, for the mobile app, the push, diagnostic, and configuration data described above) — many of these requests are satisfied by actions you can take yourself (deleting local history, revoking devices, turning off notifications, uninstalling). For anything else, contact us and we will respond as required by applicable law. You may also have the right to lodge a complaint with your local data-protection authority. We may need to confirm details of your request before acting on it.

24. International Processing

CouchCode is operated from Estonia, and its relay and website are hosted on infrastructure that may be located in other countries. The Firebase services used by the mobile app are operated by Google and may process data in other countries as well. If you connect through the relay or use these features, your data may be processed in a country other than your own, which may have different data-protection laws. Where required by applicable law, international transfers are supported by legally recognised safeguards, such as adequacy decisions or contractual protections used by the relevant service provider. You can contact us for more information about the safeguards applicable to a particular processing activity.

25. Children

CouchCode is a developer tool intended for adults. It is not directed at children, and we do not knowingly collect personal information from children. If you believe a child has provided us information, contact us and we’ll address it.

26. Changes to This Policy

We may update this policy as the product evolves. When we do, we’ll change the “Last updated” date above, and for material changes affecting how data is handled, we’ll make a reasonable effort to highlight them. If a new feature changes what data is processed, we’ll update this policy before — or as — that feature ships.

27. Contact

For any privacy question or request:

CouchCode
our email address