Security review: API keys are NOT end-to-end encrypted

[rootux]

TLDR

The server operator (or anyone who compromises the server or its HANDY_MASTER_SECRET env var) can read every stored API key (Anthropic, OpenAI, Gemini).**

I (Well opus 4.6) did a source code review of Happy and wanted to flag something that I think the community should be aware of, especially anyone using happy connect with their Anthropic/OpenAI/Gemini API keys.

The claim

Happy's README and privacy policy emphasize "zero-knowledge encryption" and E2E encryption. This is true for session content (conversation data).
However, it is not true for your API keys when using the connect feature.

What actually happens

When you run happy connect claude (or openai/gemini), your API token is sent to the Happy server and encrypted with the server's own master secret — not your personal encryption key.

The server-side encryption key is derived from an environment variable the server operator controls:

https://github.com/slopus/happy/blob/main/packages/happy-server/sources/modules/encrypt.ts#L5-L10

export async function initEncrypt() {
      keyTree = new KeyTree(await crypto.deriveSecureKey({
          key: process.env.HANDY_MASTER_SECRET!,  // <-- server operator's key
          usage: 'happy-server-tokens'
      }));
  }

Your API token is encrypted with this key and stored in the database:

https://github.com/slopus/happy/blob/main/packages/happy-server/sources/app/api/routes/connectRoutes.ts#L260

const encrypted = encryptString(['user', userId, 'vendors', request.params.vendor, 'token'], request.body.token);

And the server can decrypt and return it as plaintext at any time:

https://github.com/slopus/happy/blob/main/packages/happy-server/sources/app/api/routes/connectRoutes.ts#L290
return reply.send({ token: decryptString(['user', userId, 'vendors', request.params.vendor, 'token'], token.token) });

This means the server operator (or anyone who compromises the server or its HANDY_MASTER_SECRET env var) can read every stored API key.

Why this matters

This is standard server-side encryption at rest — fine for many use cases, but it is not E2E encryption, and the distinction
matters. Users who read "zero-knowledge encryption" may reasonably assume their API keys are protected the same way their
conversation data is. They are not.

Additional context

The daemon feature also means a compromised Happy account can spawn Claude Code sessions on your machine remotely
(https://github.com/slopus/happy/blob/main/packages/happy-cli/src/daemon/run.ts#L219). The OAuth token is passed from the relay
server directly into the spawned process (https://github.com/slopus/happy/blob/main/packages/happy-cli/src/daemon/run.ts#L289).
This is a documented feature, not a bug, but it's worth understanding the trust model.

Discussion

Perhaps I'm missing something.
I'll send a separate comment to suggest how to fix this

Thanks to @sshoing for discovering this

[rootux]

Suggested fix: client-side encryption for vendor tokens

The infrastructure to do this properly already exists. Session data is E2E encrypted using the client's machineKey (AES-256-GCM)
stored in ~/.happy/access.key (https://github.com/slopus/happy/blob/main/packages/happy-cli/src/persistence.ts#L487-L495). The
encryptWithDataKey / decryptWithDataKey functions
(https://github.com/slopus/happy/blob/main/packages/happy-cli/src/api/encryption.ts#L120-L178) are well-implemented: AES-256-GCM
with random 12-byte nonces, proper auth tags, and versioned bundles.

Vendor API tokens should use the same path.

  Current flow (server encrypts)

  CLI                              Server
   |                                 |
   |-- POST /connect/anthropic/register -->
   |   { token: "sk-ant-..." }       |
   |                                 | encryptString(HANDY_MASTER_SECRET, token)
   |                                 | store encrypted blob in DB
   |                                 |
   |-- GET /connect/anthropic/token -->
   |                                 | decryptString(HANDY_MASTER_SECRET, blob)
   |   <-- { token: "sk-ant-..." } --|

Proposed flow (client encrypts)

  CLI                              Server
   |                                 |
   | deriveVendorKey(machineKey)     |
   | encryptWithDataKey(vendorKey,   |
   |   "sk-ant-...")                 |
   |-- POST /connect/anthropic/register -->
   |   { token: <encrypted blob> }   |
   |                                 | store blob as-is (opaque to server)
   |                                 |
   |-- GET /connect/anthropic/token -->
   |   <-- { token: <encrypted blob> } --
   | decryptWithDataKey(vendorKey,   |
   |   blob)                         |
   | => "sk-ant-..."                 |

Concrete changes

1. Derive a purpose-specific key (don't reuse machineKey directly)

Using machineKey directly for vendor tokens creates domain overlap with session encryption. If a nonce were ever reused across
purposes, GCM security breaks. Cheap insurance:

  import { createHmac } from 'node:crypto';

  function deriveVendorEncryptionKey(machineKey: Uint8Array): Uint8Array {
      return new Uint8Array(
          createHmac('sha256', machineKey)
              .update('happy-vendor-token-encryption')
              .digest()
      );
  }

2. CLI side — encrypt before sending, decrypt after receiving

  import { encryptWithDataKey, decryptWithDataKey, encodeBase64, decodeBase64 } from './api/encryption';
  import { readCredentials } from './persistence';

  const creds = await readCredentials();
  const machineKey = creds.encryption.type === 'dataKey' ? creds.machineKey : creds.secret;
  const vendorKey = deriveVendorEncryptionKey(machineKey);

  // Registering: validate then encrypt
  if (!looksLikeValidToken(vendor, apiToken)) {
      throw new Error('Token format does not match expected format for ' + vendor);
  }
  const encryptedToken = encodeBase64(encryptWithDataKey(apiToken, vendorKey));
  await api.post(`/v1/connect/${vendor}/register`, { token: encryptedToken });

  // Retrieving: decrypt, handle key mismatch gracefully
  const response = await api.get(`/v1/connect/${vendor}/token`);
  const blob = decodeBase64(response.token);
  const plainToken = decryptWithDataKey(blob, vendorKey);
  if (plainToken === null) {
      // Key changed (re-auth, new machine, etc.) — prompt re-registration
      console.log(`Token for ${vendor} cannot be decrypted. Please re-run: happy connect ${vendor}`);
  }

3. Server side — become a dumb blob store

https://github.com/slopus/happy/blob/main/packages/happy-server/sources/app/api/routes/connectRoutes.ts#L258-L267 — POST endpoint:

    async (request, reply) => {
        const userId = request.userId;
  -     const encrypted = encryptString(['user', userId, 'vendors', request.params.vendor, 'token'], request.body.token);
  +     // Token arrives already E2E encrypted by client — store as-is
        await db.serviceAccountToken.upsert({
            where: { accountId_vendor: { accountId: userId, vendor: request.params.vendor } },
  -         update: { updatedAt: new Date(), token: encrypted },
  -         create: { accountId: userId, vendor: request.params.vendor, token: encrypted }
  +         update: { updatedAt: new Date(), token: request.body.token },
  +         create: { accountId: userId, vendor: request.params.vendor, token: request.body.token }
        });
        reply.send({ success: true });
    });

https://github.com/slopus/happy/blob/main/packages/happy-server/sources/app/api/routes/connectRoutes.ts#L281-L292 — GET endpoint:

    async (request, reply) => {
        const token = await db.serviceAccountToken.findUnique({ ... });
        if (!token) {
            return reply.send({ token: null });
        } else {
  -         return reply.send({ token: decryptString(['user', userId, 'vendors', request.params.vendor, 'token'], token.token) });
  +         // Return E2E encrypted blob — only the client can decrypt
  +         return reply.send({ token: token.token });
        }
    });

Same change for the bulk endpoint at
https://github.com/slopus/happy/blob/main/packages/happy-server/sources/app/api/routes/connectRoutes.ts#L324-L332 — remove the
decryptString loop, return blobs as-is.

4. Remote/mobile sessions — daemon self-serves tokens

This is the part that breaks if you only do steps 1-3. Currently, when the mobile app triggers a remote session, the server
decrypts the vendor token and passes it via RPC to the daemon. With client-side encryption, the server can no longer do this.

The fix: the daemon already runs on the user's machine with full access to ~/.happy/access.key. Change the spawn-session flow so
the daemon reads and decrypts vendor tokens locally instead of receiving them through the relay:

https://github.com/slopus/happy/blob/main/packages/happy-cli/src/daemon/run.ts — in spawnSession:

    const spawnSession = async (options: SpawnSessionOptions): Promise<SpawnSessionResult> => {
  -     // Use token from RPC options (decrypted by server)
  -     if (options.token) {
  -         authEnv.CLAUDE_CODE_OAUTH_TOKEN = options.token;
  -     }
  +     // Decrypt vendor token locally — server never sees plaintext
  +     const creds = await readCredentials();
  +     if (creds?.encryption.type === 'dataKey') {
  +         const vendorKey = deriveVendorEncryptionKey(creds.encryption.machineKey);
  +         const vendor = options.agent === 'codex' ? 'openai' : 'anthropic';
  +         const encryptedBlob = await fetchVendorTokenBlob(vendor);
  +         if (encryptedBlob) {
  +             const token = decryptWithDataKey(decodeBase64(encryptedBlob), vendorKey);
  +             if (token) authEnv.CLAUDE_CODE_OAUTH_TOKEN = token;
  +         }
  +     }

The mobile app's spawn-session RPC would then only send { directory, agent } — no token field needed.

5. Multi-device support — schema change

machineKey is per-machine, so encrypted tokens are per-machine. If a user has Desktop A and Desktop B, each encrypts independently.
The DB unique constraint needs to change:

  - @@unique([accountId, vendor])   // current
  + @@unique([accountId, vendor, machineId])  // proposed

Each machine registers its own encrypted copy. This is arguably better security — compromising one machine's key doesn't expose
tokens registered from another.

Migration

Recommended: force re-registration. Invalidate all stored tokens and prompt users to re-run happy connect . This is a one-time action, avoids any vulnerability window, and is simple to implement.

A server-assisted migration (server decrypts old tokens, returns to client, client re-encrypts) technically works but creates a window where plaintext tokens transit the network — which contradicts the narrative of the fix.

Why this works

• machineKey is generated on the client and never leaves the device
• encryptWithDataKey is already battle-tested for session E2E encryption
• Purpose-specific key derivation prevents domain overlap
• The server becomes a dumb blob store — genuinely zero-knowledge
• The daemon self-serves tokens locally, so remote sessions keep working
• No new crypto dependencies needed

[778wk88pxn-byte]

I keep getting this error for no reason