Privacy

Version 0.3.0 · Effective 1 October 2026

Codiz is a desktop app that runs coding agents: Claude Code, Codex and Cursor. Codiz itself runs on your machine. The agents do not. They send your code to their own vendors, and that is the difference worth remembering.

  • Your code goes to the engine you pick

    Claude Code sends it to Anthropic, Codex to OpenAI, and Cursor to Cursor. Each vendor handles it under its own terms, the same as using its tool directly.

  • Voice is local

    Speech-to-text and text-to-speech run entirely on your machine. Your microphone audio never leaves the device.

  • Your work stays put

    Conversations, transcripts and project memory are saved on your own computer. Codiz does not upload them anywhere.

  • No analytics in the app

    Codiz collects no usage analytics. Crash reports and a short record of each run go to the developer through Sentry. This website is measured separately.

1. What runs locally

Microphone audio. The mic is off until you turn it on to dictate. It records until you turn it off, and the mic is released every time. Speech is transcribed on-device by a bundled Whisper base.en model. The raw audio is not stored and is not sent anywhere.

Speech synthesis. Spoken answers are generated on-device by a bundled Kokoro 82M voice model. No cloud voice service is used. The sound cues are made on your machine too, from a few tones. There are no audio files.

Model weights. The voice and transcription models ship inside the app and load from disk. The app is explicitly forbidden from downloading models at runtime (allowRemoteModels = false), so voice works fully offline.

2. What is sent to the engine vendors

Codiz does not run its own AI backend and has no server of its own. It drives the engine you pick, on your machine, using your existing login with that vendor. Codiz never asks for an API key and never handles model billing.

  • Claude Code runs through Anthropic’s Claude Agent SDK. Your code goes to Anthropic.
  • Codex runs through your own codex CLI. Your code goes to OpenAI.
  • Cursor runs through your own cursor-agent CLI. Your code goes to Cursor.

When you send a message or run a turn, these are sent to that engine’s vendor:

  • Your prompts and messages, and any images you attach.
  • The contents of files the agent reads, and the code it is asked to work with.
  • Commands the agent runs and their output, and other tool inputs and results.
  • Conversation and session identifiers used to resume context.
  • Relevant saved memory for the project (§3a), and the text of any skill you invoke.

Some cases send your code somewhere you might not expect:

  • Teams. A conversation can run several agents at once, and each member can use a different engine. Each member’s work goes to its own vendor. So one conversation can involve more than one company.
  • Changing engine. Moving a conversation to another engine sends that conversation’s context to the new vendor, so it can catch up.
  • Work the app starts for you. Naming a conversation from your first message, AI review, and writing project memory each run on an engine. They send what they need to that engine’s vendor, the same way a turn does.

Each vendor handles this data under its own privacy policy and the terms of your account with them. Codiz is not a party to, and does not control, that processing. If you do not want a piece of code or information sent to a vendor, do not include it in a turn.

3. What is stored on your device

Codiz keeps your work in a SQLite database in the operating system’s per-user application-data folder (userData/codeio.db). That includes projects, conversations, turns and messages, including your prompts and the full text transcripts of the agents’ responses. It also holds file paths and tool metadata, the speech timeline and cues, a symbol index of your code, and your settings.

This database is stored unencrypted. On macOS and Linux the file is readable only by your user account. It is only as protected as that account and your disk. API keys you give an MCP server in Codiz are the exception: they are locked with your system’s own secure storage, such as the macOS keychain, where one is available.

Codiz does not copy the database off the device. You can delete your data by removing conversations in the app, or by deleting codeio.db from the app’s data folder. Uninstalling does not delete it for you.

Some things are kept as files outside the database:

  • Worktrees. A conversation can work in its own checkout of your repository. These checkouts live in the app’s data folder, not inside your repository.
  • Images and recordings. Images you attach, images an agent produces, and recordings made in the built-in browser are saved in the app’s data folder.
  • Checkpoints. At each end of every turn, Codiz takes a snapshot of the project folder into hidden refs inside your own repository’s .git (under refs/codeio/). They stay on your machine. Review and revert read them. They are deleted when you mark a conversation done. Your HEAD, index and working files are never changed by this, and files ignored by .gitignore are never captured.

3a. Project memory

Codiz can keep notes on what a project’s conversations settled on: a decision and its reason, a dead end, a preference. These are markdown files you own. They are written to the app’s data folder, never inside your repository. You can read, edit or delete them directly.

Writing them involves an engine, so the relevant part of a finished conversation is sent to that vendor to be turned into notes. Relevant notes are then included at the start of later turns (§2), and agents can search them on request. Memory can be switched off per conversation, per project or for the whole app. The project’s Memory page lists everything remembered.

4. Network activity

These are the connections made while Codiz runs:

  • Each engine talking to its own vendor to run a turn (§2).
  • Any network access the agent performs because you asked it to, such as a command that reaches the internet.
  • git reaching your own remote when you pull or push, and your git host (GitHub or GitLab) when you work with pull requests.
  • A check for a new version of Codiz, against its public releases on GitHub. It runs shortly after launch and then every six hours. An update is only downloaded when you choose to.
  • Downloads you start with an Install button. An engine’s CLI comes from its vendor’s own installer. gh or glab comes from that project’s official releases.
  • MCP servers. Your engines connect to the servers they are configured to use. When you add a remote server to Codiz’s own list, Codiz contacts it to see whether it needs a sign-in.
  • Pages you or an agent open in the built-in browser.
  • Crash and error reports, if they are on, and a short record of each run of the app, which is sent either way (§5).
  • Feedback, when you press Send on the Feedback form (§5a).

The app sends no usage analytics. Apart from the reports in §5, nothing about how you use it is sent. The website is measured separately (§6).

4a. The page for your phone

While Codiz runs, it serves a page on your local network so you can follow your conversations from a phone. It listens on port 7420. Nothing about it goes through an outside server.

A device sees only a locked page until you pair it. You pair it by scanning a QR code in the app. The code works once and expires after a minute. A paired phone can read your conversations and the pictures in them, send messages, and answer an agent’s questions. You can unpair a phone from the same panel in the app.

The page uses plain HTTP, not HTTPS. Anyone who can read the traffic on your network could read what the page shows.

5. Crash and error reporting

To find and fix bugs, Codiz sends crash and error reports to the developer through Sentry, a crash-reporting service. It is on by default, because a crash nobody hears about cannot be fixed. Two things are sent: error reports, and a short record of each run.

When an error report is sent. When the app crashes, or hits an error that nothing in it handled. That covers the app’s background process and its window. If the whole app crashed, the report is sent the next time you open Codiz.

What an error report holds.

  • The error’s message and stack trace, with the surrounding lines of Codiz’s own source code where they are available.
  • For a native crash, a crash dump. It records the state of the crashed process, and can hold fragments of whatever that process had in memory at the time.
  • The app version, your operating system and its version, your processor, memory, screen size and graphics card, and your language and time zone.
  • A trail of up to the last 100 things that happened before the error. That means lines the app wrote to its log, buttons you clicked (by their label), windows opening and closing, and the web addresses of requests the app made and of pages it showed, including pages in the built-in browser.

Codiz does not attach your conversations, prompts, files or microphone audio to a report. It does not capture the values held in the code’s variables. It sets no user ID, and tells Sentry not to record your IP address with a report (sendDefaultPii: false). The request and user fields are removed before a report is sent.

That still does not make a report free of your work. An error message or a log line can name a file path, a branch or a conversation’s title, and titles are made from your first message. A crash dump can hold a piece of text the app was handling. So we do not promise that a report never contains any of it.

The record of each run. Separately, Codiz sends Sentry one short record for each time the app runs. It goes when you quit, or the next time you open Codiz if the app did not close cleanly. It holds a random ID for that run, when it started, how long it lasted, whether it ended normally, a count of errors, and the app version. It holds no content and no user ID. Like any request over the internet, it reaches Sentry from your network address.

What the switch does. The switch is in Settings → About → Crash & error reporting. Turning it off stops every error report, from every part of the app, at once. Errors are then written only to a local log file (userData/logs/errors.log), and crash dumps are deleted without being sent.

The switch does not stop the record of each run. That is sent with the switch on or off, and no setting turns it off today. The switch does not cover Feedback either (§5a), which goes only when you press Send.

If you are offline, whatever is due to go waits on your computer and is sent once you are back online. A copy of Codiz built without a reporting key sends nothing to Sentry at all.

5a. Feedback you send

The Feedback button in the sidebar sends a bug report or an idea to the developer, also via Sentry. Nothing is sent until you press Send. A report holds:

  • What you wrote, and whether you chose Bug or Idea.
  • Your email, only if you typed one, so the developer can reply.
  • The app version, your operating system and architecture, and the newest lines of the local error log.
  • The same device details and trail of recent activity that an error report carries (§5).
  • A picture of the Codiz window, only if you tick “Add a picture of the window”. It shows whatever was on screen when you opened the form, which may include your code.

A report does not attach your conversations, prompts or files. But the error log, the trail and the picture can show pieces of them, such as a file path or a conversation’s title. Pressing Send is you asking for that one report to go, so it is sent even when crash reporting is off.

6. Analytics

In the app, there is none. The app does not count or track which features you use. The reports in §5, with their trail of recent activity, are the only reporting it does. If analytics are ever added they will be opt-in, off by default with a toggle in Settings. They will also be content-free: event counts and error categories only, never your code, prompts or transcripts.

This website is a different thing, and it is measured. The site uses Google Analytics 4 to count visits, so we know which parts are worth keeping. It records the usual web measurements: pages viewed, approximate location derived from your IP address, referrer, device and browser. It sets cookies in your browser to recognise a repeat visit. It also counts clicks on the download links, with the file and version you chose. That data is processed by Google under Google’s privacy policy.

The download buttons also ask GitHub for the newest release, from your browser. The files themselves are served by GitHub.

All of this applies to the website only. Nothing about it reaches the app: the two share no identifier, and installing Codiz does not carry any of it with it. Browser tracking protection or an ad blocker will stop the analytics, and the site works the same with them blocked.

7. Children

Codiz is a developer tool and is not directed to children under 13, or the equivalent minimum age in your jurisdiction.

8. Changes

This policy will be updated as the product changes. Material changes are reflected in the version and date at the top. Continued use after an update means you accept the revised policy.

9. Contact

There is no privacy email address yet. There are two ways to reach the developer today.

  • In the app. The Feedback button in the sidebar sends your message to the developer (§5a). It does not appear anywhere public. Add your email if you want a reply.
  • On GitHub. Open an issue on Codiz’s public releases repository. You need a GitHub account. Anyone can read these issues, so do not put anything private in one.