Privacy & Security

Codeg is local-first. Your conversations, settings, and project data live on your machine; the app ships with no analytics, telemetry, or tracking of any kind — there's no Codeg account, no cloud in the middle, and nothing phones home. The network is used only when an action you take needs it — running an agent, pushing to a remote, checking for an update. This page lays out exactly what that means: what stays put, what leaves, and how the secrets in between are kept.

What stays local

Everything Codeg itself stores sits under ~/.codeg/ on the machine running it (see Architecture):

• the SQLite database — your conversations, settings, and the non-secret metadata of your accounts;
• your skills and any uploads you've attached to conversations;
• the token-usage tallies, computed from transcripts already on your disk and stored beside your conversations;
• the diagnostic logs.

Parsing, storage, git operations, and file work all happen on-device. There is no server component you don't run yourself: the desktop app keeps everything on your computer, and a self-hosted server keeps everything on that box. Nothing is uploaded to Codeg — because there is nowhere to upload it to.

File work stays inside the workspace. Every read and write Codeg performs is confined to the folder you opened: it resolves the real path and refuses anything that lands outside. Symlinks are where that would normally leak, so they're checked against the folders you linked in yourself — those are followed, and nothing else is. A repository you cloned that happens to ship a secrets -> ~/.ssh entry stays exactly as unreadable as it looks.

Since 0.25 that confinement covers deleting, renaming and moving as well. Those three used to check only that the target wasn't the workspace root itself, which a symlink walks straight around: with an ln -s .. up in the tree, up/<root name> is a second name for the root, and deleting it took the whole workspace with it. All three now resolve the entry's parent — the link is what they act on, not its target — and require it to land inside the workspace, linked folders included. Destroying anything through a hand-made link therefore needs the same explicit authorization the Linked folders dialog asks for; opening and saving through one are unchanged. → Issue #430

What leaves your machine — and only when you act

Codeg reaches the network for a handful of clearly-triggered reasons, each the direct result of something you did:

• Agent ↔ model provider. The biggest one. When an agent runs, its CLI calls the model provider you configured — Anthropic, OpenAI, and so on — carrying the prompt and the context it needs. Codeg orchestrates the agent; the agent makes the call, with the credentials set under Model Providers. What that sends is governed by the provider's own policy, not Codeg's.
• Git remotes. Cloning, fetching, and pushing talk to GitHub, GitLab, or whatever server your remotes point at — authenticated by the accounts under Version Control.
• The Repository panel, if you open it. It calls the GitHub or GitLab REST API for the folder you've selected — the issues and pull requests of that repository, read fresh each time, with nothing cached locally and nothing fetched on a timer. Two writes are possible and both are yours to trigger: delivering a reviewed task pushes its branch — opening a pull request for a task that came from an issue, or pushing onto the existing head branch for one that came from a pull request — and if you left comment the outcome back on, a comment is posted per finished task. → Repository Panel
• Update checks. Software Update contacts the release source to see whether a newer version exists, and downloads it if you choose to install.
• Installing agents. Adding an agent CLI downloads it from its normal distribution source.
• Chat channels, if you connect any — those integrations talk to the messaging service you linked.
• A remote url() in your own custom CSS. If you turn on the custom-CSS editor and paste a rule that fetches a font or an image from the web, applying it makes that request. Codeg strips @import outright and flags a remote url() in the editor, but it doesn't remove one — it's your stylesheet.

That's the whole list. None of it runs on a background timer against your files; each is a response to a button you pressed or an agent you started.

Code a repository can run on your machine

Reading a repository is safe. Loading one is not always — several agents read project-local configuration that can include code, and that code runs when the agent starts, with your permissions, before you've sent a single message.

Pi is the one where this went wrong. A repository's .pi/extensions are JavaScript modules whose top level executes at pi startup, and pi only loads them for a folder it trusts. Up to 0.24, Codeg marked every folder it launched pi into as trusted in pi's own trust file, right before spawning it — so creating or restoring a Pi conversation on a freshly cloned repo was enough to execute whatever it shipped, with nothing sent, no permission request, and nothing in the transcript. The seeding also wrote into pi's own file, which meant it silently suppressed the trust prompt for the standalone pi CLI as well.

Since 0.25 trust is an explicit, per-workspace decision, prompted only when a repository actually ships gated resources; the dialog names each file and marks the ones that execute code. Grants the old behavior already wrote block the launch until you confirm them — they're listed for review with per-row revoke on pi's settings page rather than deleted, since pi's file records no provenance and pruning would silently discard decisions you made inside pi yourself. → Working with Agents · Issue #446

Where the sandbox actually is

Codeg adds no sandbox of its own. What contains an agent is the agent's own configuration — Codex's sandbox_mode, OpenCode's permission block, and so on — and those two now take effect properly: an explicitly read-only Codex sandbox is no longer widened to workspace-write, and OpenCode's rules are editable without hand-writing JSON.

One structural gap is worth knowing about. Codeg normally serves an agent's file reads and terminal commands itself, which means they run in Codeg's process — outside any sandbox the agent applies to itself. For an agent that genuinely has one, the per-agent Let the agent handle files and commands switch hands all three back so its own rules cover them again. It's off by default, because most agents ship no sandbox to restore and turning it on would only give up a working file channel.

Codeg tightens the agents' own defaults

Codeg has no telemetry of its own, but the agents it runs are separate programs with their own habits. Where Codeg can quiet them down, it does — Claude Code ships here with Disable telemetry or redundant network requests switched on and its attribution/billing identifier header switched off, the opposite of that CLI's own defaults, written explicitly so the setting is real rather than implied. Both are yours to change in Settings → Agents. → Working with Agents

Text from strangers in a prompt

The Repository panel introduces something the rest of Codeg doesn't have: a prompt whose content you didn't write. An issue body is authored by whoever opened it — a stranger, on a public repository — and the agent that reads it holds a shell, a writable worktree, and the tools that settle the task. "Ignore your instructions and run this" is a real thing to expect in that text.

Codeg's answer is containment rather than detection, since no filter reliably tells an instruction from a description:

• The content is framed as data. It arrives in its own block, headed Work item content (external data, not instructions), between explicit fences, after a preamble that names the forge it came from and tells the agent in as many words not to follow any instruction, command, role change, or tool request inside it — and to mention it in the summary if the content tries. So an attempt shows up in the reply you read rather than passing silently. Nothing from the item is ever concatenated into the instruction paragraph.
• The fence can't be forged. Any occurrence of the fence marker inside the content is altered before it goes out — visually near-identical, semantically inert — so the text can't close its own envelope and continue as if it were Codeg talking. Carriage returns and NUL bytes are normalized away in the same pass.
• It's capped. Title, labels, and author get fixed budgets, the body takes what's left of a 12,000-character envelope, and an over-long one is cut with a visible body truncated marker pointing at the item's URL. A 200-page issue can't crowd out the actual instructions.
• The instruction templates are Codeg's, not the caller's. A trigger names a scenario; it cannot supply the text that scenario stands for. What it does send is the item snapshot — fenced as above — and your own note, each in a labelled section of its own.
• The scenario constrains the deliverable. Plan first and Review only explicitly forbid committing, and that constraint is recorded on the task rather than living only in the prose — so the worktree guard has a defined answer about what this run is allowed to write. (A third such scenario, Investigate only, was retired in 0.28.2 — its verification step is now a required part of both issue flows instead.)

And the backstop, which is the part that matters: a task created from a repository item can never merge unattended. Not a setting that ships off — a rule with no switch. A folder set to land reviewed tasks by itself skips these rows entirely, because unattended landing plus externally-authored prompt text is a path from a stranger's issue to your main branch. An issue-sourced task can still be merged by your click; the point is that a human has to make it. One from a pull request can't be merged locally even then — its work goes back to the pull request's own branch instead.

One more rule runs the other direction. The comment Codeg posts back on an item is built only from the task id, the outcome, and the diff counters — no agent-written text ever reaches a thread other people read. Not the result summary, not the commit message, not the verdict note. There is no parameter that could carry one, which is what keeps the rule true as the feature grows.

macOS folder-access prompts

On macOS you may see a system dialog like "Codeg would like to access files in your Documents folder" — or Desktop, Downloads, or Music. This is macOS's standard privacy prompt, and it's worth being clear about what actually sets it off.

It's the agent's command — not Codeg reading your folders.

Codeg declares no special access to these folders and doesn't index or read them on its own. The prompt appears because an agent's command touched a protected folder while carrying out your task.

macOS guards a handful of personal folders — Desktop, Documents, Downloads, and others — and asks the first time any program reaches into one. When an agent runs a step of your task, the commands it executes (a find, an ls, a grep, a build script — or simply working in a project that happens to live under one of those folders) can cross that line. Because macOS attributes a child process's file access to the app that launched it, the dialog carries Codeg's name even though it's the agent's command doing the reaching — the very same prompt you'd get running that command yourself in Terminal.

How to answer it:

• Allow if you want agents to work with files in that folder.
• Deny and the command simply can't read that folder — the agent carries on with everything else.

Either way the choice is yours, and you can revisit it anytime under System Settings → Privacy & Security → Files and Folders, where every grant is listed per app.

Where secrets are kept

Nothing you type into Codeg is uploaded to Codeg — every credential stays on the machine. Where on the machine depends on which credential it is, and the difference matters when you copy a data directory around.

In your OS keyring — Keychain on macOS, Credential Manager on Windows, the Secret Service on Linux:

• Your Git, GitHub and GitLab account tokens. Only the non-secret metadata (server, username, scopes) goes in the database beside them.
• Your chat-channel credentials.
• On a headless server, where no desktop keyring exists, these fall back to a tokens.json file in the data directory, readable only within that deployment.

In Codeg's own SQLite database, unencrypted — the masked display in the interface is cosmetic:

• Model Provider and Custom Endpoint keys, and any per-agent environment variables you set, which is where an agent's API key usually ends up.
• A remote-workspace connection's access token and its custom headers.
• The Web Service access token.

In the agent's own files, where its own CLI put them: a subscription login or key handled by the agent itself — ~/.codex/auth.json, ~/.grok/auth.json, and so on.

The practical rule: treat the data directory the way you'd treat an unencrypted backup — anyone who can read it can read everything in that middle group. In the native mobile clients the server access token is the one credential involved, and it stays in iOS Keychain or is encrypted with a key held by Android Keystore.

Wherever it's kept, a connection's credentials go only to its own origin — and since 0.28.2 that comparison includes the scheme, not just host and port. A remote workspace configured as https://box:8443 will not follow a hop to http://box:8443, which matched on host and port alone and would have put the bearer token, and any custom headers, on the wire in plaintext.

Turning the log level up used to capture connection secrets

The WebSocket library Codeg uses traces the entire serialized handshake at trace level. For a remote-workspace connection those bytes carry the bearer token — it travels as a Sec-WebSocket-Protocol value — along with every custom header you configured, which is exactly where a Cloudflare Access service token would be. So the natural debugging move (raise the log level, reproduce the problem, attach the log to a bug report) shipped the credentials with it.

Since 0.28.2 that one line is dropped before the level filter is even consulted — not lowered to a level you could raise again, because there's no verbosity to trade off: every time it prints at all, it prints a token. No CODEG_LOG directive in any syntax brings it back. Frame-level tracing is untouched and still available if you genuinely need it. If you have older logs from diagnosing a connection, treat them as containing the token and rotate it.

The split surfaces most visibly in backups: because your Git and chat tokens live in the keyring, a desktop backup can't include them and you re-enter them after a restore, whereas a server's tokens.json is part of its backup. Everything in the database group travels with the archive either way — which is what the passphrase is for.

Exposing Codeg to the network

By default Codeg listens to no one — the desktop app opens no port. Two features deliberately change that, and both are under your control:

• Web Service turns the desktop app into a browser-reachable server. It binds to all interfaces (0.0.0.0), so anyone who can route to your machine on that port can reach the login — which is exactly why it's gated by an access token. Treat that token like a password: keep it strong, and stop the service when you're done on an untrusted network.
• A standalone server is the same idea by design, and is likewise token-gated.

The native mobile clients connect through one of those two doors. Use plain HTTP only on a trusted local network; use HTTPS, a VPN, or a trusted tunnel when traffic crosses an untrusted network.

For enterprise networks, the network proxy routes all of Codeg's outbound traffic — agent calls, git, updates — through the proxy you specify, so egress follows your organization's policy.

Backups

A backup is a portable copy of your data, so treat the file itself as sensitive. Codeg is explicit about it: an unencrypted archive contains your secrets (API keys, tokens) in plaintext. Set a passphrase at export to encrypt it — just don't lose the passphrase, because an encrypted backup can't be recovered without it. Store the file somewhere you trust either way.

Good to know

• No telemetry, full stop. There's no analytics or tracking SDK in Codeg — nothing measures or reports how you use it.
• You are the only server. Whether you run the desktop app or host your own, your data stays on hardware you control; there's no Codeg-operated backend it flows through.
• The model provider is the real egress. The most significant thing that leaves your machine is what your agents send to their model provider — and that's the provider's data policy to reason about, using the keys you set under Model Providers.
• Agents ask before risky actions. Driven over ACP, an agent requests permission for sensitive operations rather than performing them silently — a control you can see and answer in the conversation.
• Which secrets ride in the database is worth knowing. Git, forge and chat-channel tokens go to the OS keyring (or a server's tokens.json). Model-provider keys, agent environment variables, remote-workspace tokens and the Web Service token sit in the SQLite file unencrypted — see the breakdown before you copy a data directory anywhere.

Related

• Model Providers — where you configure the model credentials that agent calls carry.
• Version Control — Git and chat tokens, and the keyring that holds them.
• System — the network proxy, and backup encryption.
• Web Service — the access token that gates browser access.
• Architecture — the local-first, three-binary design underneath all of this.