Codelux AI has always been local-first: the memory your AI writes, the notes, the timeline and the index of your code live on your machine. The Team plan had to keep that promise while doing something that looks like the opposite — moving memories, notes, the timeline, edit history, file locks and a chat between several machines, through our servers. Here is how the two fit together.
The short version
Everything a team shares is encrypted on your machines with a key that is generated on the team owner's machine and that we never receive. What travels through our servers, and what stays there, is ciphertext plus the little that is needed to deliver it. We can count your events; we cannot read them.
Where the key comes from
When you create a team on the site, you give it a name, pick the project it will share, add the members and choose how files are shared. Nothing cryptographic happens on the site. The first time the owner's Codelux AI sees a team it owns without a local key, it generates 32 random bytes — an AES-256 key — and seals them to that machine. The app shows the key as 64 hexadecimal characters behind an eye icon, with a copy button, and a sentence we repeat everywhere it appears: keep this key safe and never lose it; if it is lost, the team's shared data can no longer be read — not by you, not by us.
That sentence is the whole design. There is no button that sends the key to us, no backup on our side, no recovery form. The server records one thing about it: its version number, so that the app knows which key an event was encrypted with.
How the key reaches the other members
Two ways, and you choose.
- You hand it over. Copy the 64 characters and give them to a teammate in person, in a message, through a password manager — whatever you already trust. They paste them into Enter key on their team card.
- Machine to machine. Every Codelux AI installation generates a key pair (X25519) at first start and registers only the public half with us. When a member presses Update key from admin, their app sends a request carrying that public key; the owner's app — or any teammate who is online and already holds the key — wraps the team key in an envelope that only the requesting machine can open, and sends it back. Our realtime service carries the request and the envelope. It cannot open either.
What our servers actually store
- Memories written by the agents, with their facts, todos and CodeMaps
- Notes, forms and their history
- Timeline events — what happened, who, why
- Edit summaries
- Chat — team channel, direct messages, groups
- Which team and which project an event belongs to
- Which member wrote it, and when we received it
- A sequence number, the size, the key version
- Team name, members, roles, the project's identifier
- The folder path each member declared on each machine
- Each installation's public key
Notice what is missing from the right-hand column: the kind of event. A memory, a note, a timeline event and a chat message are all the same to our server — a sealed blob with a number on it.
One category runs in clear because it has to: the file semaphore and the online presence that stop two people — or two agents on two machines — from editing the same file at once. A lock names a path relative to the project and who holds it — never the file's contents — and it is not retained beyond the session. That is the price of having a server arbitrate "who is editing what"; we judged it a fair one.
Why source code is not in either column
Because it never goes through us. On Git clones teams, every member works on their own clone and a change reaches the others with the push, through whatever git host you already use. On Shared folder teams, everyone edits the same files on a network share or a cloud-synced folder — Dropbox, OneDrive — and the change reaches the others with the save. Codelux AI coordinates the locks around those moves; it does not carry the bytes.
What zero-knowledge costs you
It is honest to say it out loud. Because we do not have the key, we cannot help you if it is gone. Every active member holds a copy, so in practice one member who still has it — on their machine or written down — is enough to hand it round again. But if every copy is lost, the events on our servers are permanently unreadable, and there is nothing we can do about it. The Legal says so in as many words, and the app says so next to the key.
The same key also means that direct messages inside the team chat are not private towards the team. A DM is a separate channel, not a separate secret: it is encrypted with the key every member holds, and every member's app receives every event. The interface keeps the conversations apart; the cryptography does not. The app says so on every direct-message and group conversation.
When you remove someone
Removal from the site ends that person's access to new events immediately. Whatever already reached their machine stays there — we have no way to reach into their disk. When that matters, you rotate the key from the site: the owner's app mints the next version and delivers it to the members who are online through the sealed-envelope path; the others pick it up with Update key from admin. Older versions stay on everyone's machine, so the history remains readable.
What we ask in return
Treat the key like a secret, hand it only to members, and rotate it when someone leaves. And keep the realtime service in mind: while it is unreachable, writes to a shared project are refused rather than risked — better a short wait than a silent conflict tomorrow.
See the whole flow, step by step
Buying seats, creating the team, handing the key round, Git clones versus Shared folder, rotation, and what happens when the plan lapses.
Read the Teams guide →← Back to the blog | Next: What is an MCP server and why does Claude Code need one? →