Skip to content
CoDevDocs

Search guides, features, and settings.

Concepts

Security and privacy

How CoDev keeps tokens, keys, and your code isolated, and what CoDev staff can reach.

Your workspace runs code that you, your teammates, and your agents write. CoDev is built so that this code can't reach credentials it shouldn't. This page also says plainly what CoDev staff can and can't reach today, what we're changing to narrow it, and what we promise in the meantime.

Your GitHub token never enters the workspace

Terminals, agents, and Git inside a workspace never hold a GitHub token. Anyone with editor access, and any agent, can change a repository's Git config and hooks, so a token there could be read or misused.

When you push a branch or open a pull request, CoDev runs the push from a separate, isolated account, using a throwaway copy of your repository. Your token is used for that one push and never reaches the workspace's files, environment, or Git config.

AI keys stay out of the workspace

  • Your subscriptions. When you sign in to Claude or Cursor from a workspace, the sign-in runs in a private, temporary profile, and CoDev saves the result to your account, not to the workspace disk.
  • CoDev credits. When an agent runs on CoDev credits, it gets a token that works for that one turn only. CoDev's own provider keys never enter a workspace, and the turn's token is revoked as soon as the turn ends.

Processes run with the least access

  • Terminals, agents, Git, and sign-in tools start with a cleared environment and never run as the machine's administrator.
  • Agents run in their own isolated account inside the workspace.
  • Only the machine's administrator can reach the cloud metadata service. A firewall enforces that before any of your code starts.
  • Codex and Claude ignore hooks committed to your repository. Cursor won't start a turn while the repository contains Cursor or Claude hook files, because the Cursor CLI always runs them.
  • Git commands an agent runs skip the repository's Git hooks and fsmonitor, which any editor can change, so they can't run with your agent's sign-in.

Environment variables

Variables you save in your account settings are encrypted at rest. In a workspace, your agents get them through a private profile that other members can't read, never in the workspace's files. Terminals don't get them, because every editor's terminal runs as the same user. Your agents do run the workspace's code, which any editor can change, so treat a value you save as visible to that workspace's editors. See Environment variables.

Previews are kept apart from your account

The app you preview never runs on CoDev's own domain: it's either served from a separate preview domain or shown from a browser running on the workspace machine. Your CoDev session cookie stays on CoDev's domain, so a page you preview can't read or use it.

Teammates share one machine

A workspace is one machine shared by its members. Editors' terminals run as the same user, so editors can see each other's terminal environments and files. Invite people you trust with the code and any values you've saved for that workspace, and use the viewer role for people who only need to watch. See Roles and permissions.

What CoDev staff can and can't see

Administrators

CoDev administrators use an internal console. It shows account details (name, email, plan, and sign-in methods), access requests, product-wide totals, and each account's usage: how many workspaces it owns and their state, how long its machines ran, its credit balance and spending, and whether it has connected its own Claude, ChatGPT, or Cursor subscription (the provider and when, never the sign-in itself). Workspaces appear only by an internal ID.

The console has no way to open a workspace or see its name, repository, files, terminals, agent chats, members, credentials, or environment variables, and it can't sign in as you. Being an administrator doesn't make anyone a member of your workspace: every workspace permission check reads membership only. Every administrator change is recorded in an audit log.

Operators

A small number of people run CoDev's production infrastructure: the cloud account, the database, and the encryption keys. As at any hosted service, they could technically reach your data today. These are the paths:

WhatHow an operator could reach it
Files and commands in a running workspaceThe key CoDev's servers use to talk to workspace machines
Everything on a workspace machineCloud administrator commands, and a shared emergency login on each machine
Saved workspace disksDisk snapshots in CoDev's cloud account
Chats, agent output, Rooms, and files open in the shared editorThe database, where they aren't encrypted with a separate key per workspace
Saved AI credentials, GitHub tokens, and environment variablesThey're encrypted, but anyone who can use CoDev's key in its key vault can decrypt them
Your signed-in sessionThe server secret that signs session cookies

Operators use this access only to keep the service running, respond to security incidents or abuse, meet legal obligations, or help when you ask, under our Staff access policy. If we access a workspace's contents for any reason other than its owner's request, we tell the owner.

What we're changing

We're closing these paths in this order, and we'll update this page as each one ships:

  1. Alert on every cloud administrator command, disk snapshot, and use of the encryption key outside CoDev's own app, so no access goes unnoticed.
  2. Remove the shared emergency login from workspace machines. Emergency access will need approval and leave a record.
  3. Encrypt workspace disks and saved credentials with hardware-backed keys we control, and restrict who can take snapshots.
  4. Stop CoDev's servers from running commands in a workspace without a member's live session.
  5. Encrypt chats, agent output, and shared-editor files with a key per workspace.
  6. Check every signed-in session against a record the server keeps, so the signing secret alone can't create one.

Until every path is closed, we won't claim that CoDev staff can't reach your data.

Our commitments

  • We don't look at your code, chats, files, or credentials except for the reasons above.
  • We don't use your content to train AI models, and we don't sell it.
  • We open your workspace for support only when you ask, and only as far as you agree.
  • We tell the workspace owner when we've accessed its contents for any reason other than the owner's own request.
  • We tell you within 72 hours of confirming a security incident that affects your data.
  • We hand over data only for valid legal process, and we tell you first unless the law forbids it.

The full text is in the Staff access policy. For companies, the Data processing addendum covers how we process data for you and lists every service provider that handles it. The Privacy policy describes what we collect, and Data retention says how long we keep it.

Run CoDev in your own cloud

For complete separation, companies on Teams or Enterprise can run CoDev in a cloud account they own. The workspace machines, the database, and the encryption keys all live there, and CoDev staff have no access unless you grant it. See Run CoDev in your own cloud.

Protect your account

  • Turn on two-factor authentication under Settings → Security. Security changes are emailed to you.
  • Review and sign out other devices from your active sessions.
  • Password accounts must verify their email before they can sign in.

See Account settings for every option.

Report a security issue

Email admins@trycodev.com with what you found and how to reproduce it. Please don't test against other people's workspaces or accounts.