Security

CodeTeleport is designed to handle sensitive data — your AI coding sessions contain source code, file paths, and conversation history. Here’s how we protect it.

Authentication

CodeTeleport uses a two-layer authentication model:

• JWT tokens — issued on login (email/password or GitHub OAuth), expire after 7 days. Used for the dashboard and initial CLI authentication.
• API tokens — long-lived tokens with a ctk_live_ prefix, used by the CLI and MCP server. Stored as SHA-256 hashes in the database — the raw token is never stored, only the hash.

API tokens are created during codeteleport auth login and saved to ~/.codeteleport/config.json with chmod 600 (owner-only read/write).

See Authentication for setup details.

Transport

All communication between your machine and CodeTeleport servers uses HTTPS (TLS 1.2+). This includes:

• API requests to api.codeteleport.com
• Bundle uploads and downloads via presigned R2 URLs
• GitHub OAuth callbacks
• Dashboard at app.codeteleport.com

No data is ever transmitted in plaintext.

Storage

Session bundles are stored in Cloudflare R2 (S3-compatible object storage):

• Encrypted at rest by Cloudflare
• Stored in a dedicated bucket with per-user key namespacing (bundles/<user-id>/<session-id>.tar.gz)
• Presigned URLs for upload/download expire after 5 minutes
• The API server never streams bundle contents through itself — your machine talks directly to R2

User data (accounts, session metadata, device records) is stored in Turso (distributed SQLite):

• Encrypted at rest
• Passwords hashed with bcrypt (10 rounds)
• API tokens stored as SHA-256 hashes

Data Isolation

Every user’s data is strictly isolated:

• Sessions are namespaced by user ID in both the database and R2 storage
• API endpoints verify ownership before any read, write, or delete operation
• Multi-user isolation is verified in our test suite — a user cannot access another user’s sessions, devices, or tokens
• OAuth account linking matches by verified email only

Sensitive file protection

When a push bundles project memory or extra working files, a sensitive deny-list guards what leaves your machine. The following are never bundled on push and never written on pull:

• Directories: ~/.ssh, ~/.aws, ~/.config, ~/.gnupg
• Filename patterns: *.pem, *.key, *.p12/*.pfx/*.pkcs8/*.p8, *.jks/*.keystore, .env*, id_rsa/id_dsa/id_ecdsa/id_ed25519, .netrc, .npmrc, credentials

The deny-list is matched on both the original path and the resolved (realpath) basename, so a symlink pointing at a sensitive file is caught and excluded — you can’t sneak a secret in through a redirected path.

Beyond the generic deny-list, each agent adapter only bundles session state and never the agent’s own credentials or auxiliary databases — for example, Codex bundles only the rollout transcript plus the thread-inventory row, not auth.json or Codex log/memory databases. The same principle applies to every supported agent: Claude Code, Codex, and Antigravity credential files stay on your machine.

For Codex specifically, shell snapshots are excluded by default because they may contain secrets, and only apply_patch edits are auto-detected — shell (exec_command) edits are opaque, so use --include to deliberately add any temp or working files you want to travel. (Claude Code, by contrast, auto-includes files it edited via Edit/Write; Antigravity has no edited-file auto-detection, so it also relies on --include.)

Restore is also contained: on pull, files are only written inside the target project, the target agent home subtree (the restored session lives under e.g. ~/.claude/projects, ~/.codex/sessions, or ~/.gemini/antigravity-cli/conversations), and the designated temp roots (/tmp, /private/tmp). A bundle can never write outside those roots, so a malicious or malformed bundle cannot drop files into arbitrary locations on the receiving machine.

What CodeTeleport can see

Metadata we read:

• Session size, message count, timestamps
• Project name (directory basename)
• Source machine name
• AI model / agent used

Bundle contents we store but don’t inspect:

• Session bundles are opaque .tar.gz blobs
• We upload and download them without parsing their contents
• Your conversation messages and any included working files are inside the bundle but CodeTeleport never reads them server-side

What CodeTeleport does NOT do

• We do not train on your data
• We do not share your data with third parties
• We do not access your agent session directories (e.g. ~/.claude/, ~/.codex/, ~/.gemini/antigravity-cli/) on our servers — bundles are created locally on your machine
• On push we only read your local agent session data (~/.claude/, ~/.codex/, ~/.gemini/antigravity-cli/) to build the bundle. On pull we write the restored session back into those directories on the target machine — and nowhere else (see Sensitive file protection)
• We do not log or store bundle contents server-side (only metadata)

Planned: End-to-End Encryption

We plan to add client-side encryption (AES-256-GCM) so that bundles are encrypted before leaving your machine. With E2E encryption:

• The server stores encrypted blobs it cannot decrypt
• Only your devices with the encryption key can read the session data
• Key management will be handled locally

This is on our roadmap — we’ll update this page when it ships.

Reporting Security Issues

If you discover a security vulnerability, please email security@codeteleport.com (or reach out via GitHub). We take security reports seriously and will respond promptly.