Security model

How Codevre keeps the code you run apart from the editor, your account and your credentials.

Last updated 3 min read
On this page

Codevre runs code that might come from anywhere: templates, cloned repositories, npm packages, or the Agent. This page explains how that code is kept apart from the things it shouldn't touch.

Nothing runs on Codevre's servers

Link to “Nothing runs on Codevre's servers”

Your project runs in your browser, on your device:

  • static pages in VRE (localhost:codevre)
  • terminal commands, npm, builds and Node servers in Nodepod

There's no VM or container on Codevre's side, so there's no shared server that one user's code could attack. Codevre's servers only handle sign-in, saving and loading projects, storing credentials, and relaying AI requests.

Browsers isolate content by origin (scheme + host + port). Codevre uses two:

OriginWhat lives there
codevre.comThe editor UI, your sign-in session, account data, the Agent UI
preview.codevre.devThe Nodepod runtime host, its service worker, dev-server previews (/__virtual__/<id>/<port>/), and the VRE preview

Because of the browser's same-origin policy, a page on preview.codevre.dev can't:

  • read codevre.com's cookies, local storage or IndexedDB
  • read or script the editor's page
  • make authenticated requests as you to Codevre's APIs
  • read your saved AI keys or GitHub token

A page you build, a package you install, or a project someone shared with you runs on the preview origin with none of that access.

How the editor and runtime talk

Link to “How the editor and runtime talk”
  • The editor starts the runtime in a hidden iframe at https://preview.codevre.dev/nodepod/host.html and tells it the editor's origin (parentOrigin).
  • The editor posts the one-time connect message only to the exact origin https://preview.codevre.dev, and hands over a private MessageChannel port. All later traffic (file operations, processes, terminals) goes over that port, which nothing else on the page can see.
  • External preview windows connect through a relay page on the editor's origin that only accepts messages from that origin. Each window has its own random bridge id.

The IDE page is cross-origin isolated (COOP/COEP), which Nodepod needs for SharedArrayBuffer. Isolation also stops other sites from embedding or scripting the IDE. Sign-in and GitHub authorization open in a normal tab, outside the isolated page.

If the remote runtime can't start, Codevre falls back to running Nodepod on the editor's origin, and logs [Nodepod] remote runtime failed; falling back to editor-origin Nodepod. Your credentials still aren't in the runtime, but the origin separation described above doesn't apply while the fallback is in use.

Nodepod gives your code a Node.js-like environment, but it's still a browser sandbox:

  • No access to your computer's files. The file system is virtual and lives in browser memory and storage. Files only get in when you upload them.
  • No real OS processes, no native binaries, and no raw network sockets. Network access goes through the browser's fetch, so the usual browser rules (CORS, mixed content) apply.
  • Each browser tab gets its own runtime instance. Projects in different tabs don't share processes.

See What works in Nodepod.

Credentials stay outside the runtime

Link to “Credentials stay outside the runtime”
CredentialWhere it livesCan project code read it?
Codevre sessioncodevre.com (Firebase Auth)No, it's a different origin
AI provider keysYour Codevre account, used server-sideNo, they're never sent to the runtime or the preview
GitHub tokenYour Codevre account, used for single Git operationsNo, it's never in process.env and only attached to Git commands you start

The runtime is restarted whenever you sign in or out and when you connect or disconnect GitHub, so nothing from the previous session survives in a running process.

Details: Tokens and secrets.

A project can include tasks.json with commands that run when it opens. Codevre asks before running them, unless they are only cd and vre run. Approvals are tied to your account, the project, and the exact file contents; any change asks again. See Tasks.

  • The Agent works through a fixed set of tools, limited to your project folder and the runtime. See Agent tools.
  • By default it asks before running commands or deleting files.
  • Its Git commands are never authenticated, so it can't push to your GitHub.
  • Deleting the project root is refused.
  • Don't put secrets in project files you share or make public. Visibility applies to everything saved with the project, including .env files and Agent chats.
  • Review projects from others before allowing their startup tasks.
  • Rotate credentials with their provider if you think they were exposed.
  • Choose the AI provider whose data terms you're comfortable with. The provider receives the context it needs for each request.

Questions or a security concern? Contact the team on Discord (opens in a new tab).

Docs