Why Your AI Coding Agent Needs End-to-End Encryption 🔐

You’re working on a proprietary codebase. Maybe it’s your startup’s core product, your company’s internal tools, or a client project under NDA. You want to use an AI coding assistant to help you work faster—but there’s a catch.

Where is that context going?

The Problem with Remote AI Dashboards

Modern AI coding tools often include remote dashboards for:

• Viewing sessions from your phone
• Team collaboration and pair programming
• Session history and analytics

This is incredibly useful. But it also means your code, your prompts, and your AI’s responses are passing through a server that you don’t control.

Most tools ask you to simply trust that:

1. The server isn’t logging your sessions
2. No one at the company is viewing your code
3. The infrastructure is secure against breaches

But what if you didn’t have to trust anyone?

Enter: End-to-End Encryption

With GPTCode’s new Private Mode, the server becomes a blind relay. Here’s what that means:

┌─────────┐                ┌─────────┐                ┌─────────┐
│   CLI   │◄──encrypted───►│  Live   │◄──encrypted───►│ Browser │
│  Agent  │                │ Server  │                │   UI    │
└─────────┘                └─────────┘                └─────────┘
                                │
                         Cannot decrypt!

How It Works

1. Key Exchange: When your CLI connects to the dashboard, it generates a unique key pair using X25519 (the same algorithm used by Signal and WhatsApp).

2. Shared Secret: Your browser also generates a key pair. The keys are exchanged through the server, but the server only sees public keys—it can never derive the shared secret.

3. Encrypted Payloads: All session data—commands, outputs, AI responses—is encrypted with ChaCha20-Poly1305 before leaving your machine. The server relays encrypted blobs it cannot read.

4. Zero Knowledge: Even if the server is compromised, attackers get nothing of value—just encrypted gibberish.

What This Protects

The Trade-offs

Let’s be honest—E2E encryption isn’t free:

• No server-side history: We can’t store your session transcripts for later (because we can’t read them!)
• Per-session keys: A new key pair for each session means no persistent encrypted storage
• Browser compatibility: Requires modern browsers with Web Crypto support

But for teams handling sensitive code, these trade-offs are worth it.

How to Enable Private Mode

# When connecting to Live Dashboard
gptcode context live --private

# Or in your config
echo "live:
  encryption: true" >> ~/.gptcode/config.yml

Once enabled, you’ll see a 🔒 icon in your session, and the CLI will show:

✅ E2E encryption enabled
   Agent fingerprint: A1B2C3D4E5F6G7H8
   Browser fingerprint: Z9Y8X7W6V5U4T3S2

Verify the fingerprints match on first connection (Trust On First Use).

The Technical Stack

For the curious, here’s what we’re using:

We chose these because:

• X25519: Fast, secure, well-audited. Used by WireGuard, Signal, SSH.
• XChaCha20-Poly1305: Extended nonce prevents birthday attacks. No IV reuse worries.
• libsodium: When native Web Crypto isn’t available, we fall back to the gold-standard crypto library.

Open Source Transparency

Our encryption implementation is fully open source:

• CLI: internal/crypto/e2e.go
• Browser: priv/static/js/crypto.js

We encourage security audits and contributions. If you find a vulnerability, please report it responsibly.

The Bottom Line

AI coding assistants are becoming essential tools. But convenience shouldn’t come at the cost of security.

With Private Mode, GPTCode proves you can have both:

• Remote access from any device ✅
• Team collaboration features ✅
• Zero-knowledge privacy ✅

Your code stays yours. Even we can’t read it.

Try Private Mode today: gptcode context live --private

Questions? Join our Discord or open an issue.