Privacy
What we do with what you give us.
Cocode is a room where two people write code together. This page is a plain description of what the software actually does with the things that pass through it — the problem you paste, the code you type, your camera, your address if you leave one. It is written in the present tense because that is the only tense we can be held to.
Nobody here is a lawyer and this is not a legal instrument. It is an honest account of how the program behaves, written by the people who wrote the program. Last updated 29 September 2026.
What leaves your browser
Four things do. One of them is a third party, and it is first because it is the one you would most want to know about.
The problem you paste goes to Anthropic
Building a challenge means reading your problem statement and turning it into a function signature and a test suite, and that is done by Claude. The text you paste is sent to Anthropic’s API over the network, as it is, to do that. If what you paste is confidential — an unreleased interview question, something under an NDA, anything from a customer — that is the sentence to weigh before you paste it.
The code you type goes to the other person, and to the sandbox
Editing is peer-to-peer: the two browsers hold a WebRTC data channel open and the document syncs across it directly, so ordinary typing does not go through us at all. It reaches our server only when somebody presses Run. Then it is written to a temporary directory, mounted read-only into a container with no network, every Linux capability dropped and a memory and process cap, and the directory is deleted when the run finishes — pass or fail or crash.
Your camera and microphone go to the other person only
Video and audio are peer-to-peer too. Nothing in Cocode records them — there is no recorder in the code and no file for one to write to. When the two browsers cannot reach each other directly, which is roughly one pair in seven, the streams relay through our TURN server instead: it forwards encrypted media and keeps none of it.
Your network addresses, so the call can connect
Any WebRTC call has to exchange candidate addresses before it can start. Yours pass through our signaling server to the other person’s browser, and your public one is discovered by asking a public STUN server. This is how a browser call works everywhere, not something Cocode added, but it does mean the other person’s machine learns your IP address — the same as on any video call that is not relayed.
What we keep, and for how long
Almost all of it lives in one server process’s memory and dies with it. Two things on this page are kept anywhere durable: the waitlist email below, and a saved problem, if you have one.
The challenge: four hours, in memory
A built challenge — your problem text, the generated tests, the reference solution we check them against — is held in the server’s memory and expires four hours after it was made. It is never written to a disk or a database, so a deploy or a restart takes every one of them with it. The reference solution never leaves the server; your problem text is rendered back into the code shell as the docstring you see above the function.
A fingerprint of your paste, so we do not build it twice
Alongside the challenge we keep a SHA-256 hash of the exact text you pasted, and we look pastes up by it: paste the same problem again and you get the challenge that already exists instead of paying for two more model calls. It is an index, not a substitute — it lives and expires with the challenge it points at, and it is not a way of keeping the text in some safer form, because the text is right there beside it for those four hours.
The room: as long as it is open
A room is two slots in a map in one process. It holds a code and who is in it, never anything either of you typed or said. It is forgotten a short while after the last person leaves, and immediately if the server restarts — which is the literal meaning of “rooms end when you close them”.
Your email address, if you gave us one
The waitlist on /teams is the one thing here that outlives a session. The address goes to PostHog as a person — the address itself is the identifier, not a number with your address attached — along with the date and which of the two boxes you used. It is copied into one private spreadsheet, because somebody has to work through the list and note who has been replied to. Those are the only two copies: no mailing tool, no CRM, nothing sold or shared. It stays until you ask for it to go, and asking is the last section of this page.
Signing up connects your earlier visits to your address
Worth saying because it is not obvious and we would rather you heard it here. If you had been browsing this site before you typed your address, the page views from that browser are joined to the person your address creates. That is how we can tell whether the /teams page is what convinced anyone, which is the entire question that page exists to answer — but it does mean a marketing-site visit stops being anonymous at the moment you sign up. Only this site, only what PostHog already had, and nothing from inside a session: not your code, not the challenge, not the call.
What we do not collect
Said as facts about the current program, not as vows. Where one of these is going to change, the last section says so.
No account is required to use Cocode
No account is required to open a room, paste a problem or run a session — that has not changed. Signing in is optional, and it unlocks exactly one thing: saving a problem so you can reopen it later. If you save one, we keep the problem and its tests, tied to your account, until you delete it. We never keep your code, your room, your video or the reference solution. A paid tier for interviewers will eventually add accounts on the interviewer’s side too; the promise on /teams is that the person being interviewed still never makes one, and that is the half of it we will hold to.
No recording of the session
Nothing about a session is recorded: not the video, not the audio, not the keystrokes, not a replay of the room. There is no recorder in the product. Recording is the first item on the Teams roadmap, so read that as “this is not built” rather than as a promise about the future — the last section says where it is going.
No raw IP addresses in our analytics
The server rate-limits by network address, which means it sees one. It never sends one anywhere: an event is attributed to a truncated SHA-256 hash of that key, so the analytics can count how many different people hit a limit without ever holding who they were.
No reading of what you type
Analytics counts events, not content. What your code says, what the other person said out loud, what you typed and deleted — none of it is collected, and the only thing derived from your problem that ever reaches PostHog is the challenge’s short slug, a couple of words like “two-sum”.
Who else is involved
Five companies, and what each one is actually for. None of them is an advertiser and none of them is paid in your data.
Anthropic
Builds the challenge from what you paste. Your problem text goes to Claude’s API; nothing else does — not your code, not your name, not your address. This is the one on the list that receives something you wrote.
PostHog
Product analytics, hosted in the United States. It gets the events described above, and the waitlist address if you gave one. It sets cookies in your browser to tell one visit from the next, which is why you were asked before any of it started.
Google Cloud
Runs the server. Everything above that touches our side runs on machines there, including the container your code is tested in.
Google’s public STUN server
Tells your browser its own public address so a call can be set up. It is the default STUN server the whole industry points at, it sees the request and nothing else, and no media ever goes near it.
Cloudflare
DNS. It answers the question “where is Cocode”, which means it sees that the lookup happened. It does not carry the session.
Being counted is your call
PostHog captures page views and the clicks it can see automatically, plus a handful of events we name ourselves — a challenge was asked for, a run finished, a room was opened. It is how we find out which parts of this get used. None of it starts until you say yes, declining is one click in the same place as accepting, and you can change your mind here whenever you like.
Turning it off opts this browser out of PostHog entirely: no events, and the cookies it uses to recognize a returning visit are dropped too. Nothing else about Cocode changes — every part of the product works exactly the same either way, and there is no version of this page where saying no costs you a feature.
Getting your address deleted
The waitlist address is the only thing we hold that outlives your session, so it is the only thing there is to delete. Everything else expires on its own: the challenge in four hours, the room when you close it, the analytics when you turn them off.
That address is in two places, and it would be easy not to mention the second one. It is in our analytics, which is the record of the sign-up. It is also copied into a private spreadsheet that only we can open, because a list of people waiting to hear about a product is a list somebody has to actually work through — who has been replied to, who is still owed an answer. Nothing else about you is in it and it is never shared. The deletion request below covers both.
Here is exactly what the button below does, because it would be easy to imply more. It records your address as flagged for deletion in PostHog and it tells you whether that landed. A person then removes the record by hand, from the analytics and from the spreadsheet above. There is no automated delete behind it — this server holds no key that could do one — and rather than build something that looked automatic and was not, we would rather write this paragraph. If the request fails you will be told it failed, and nothing will have been flagged.
One awkward consequence, stated rather than hidden: we do not check first whether the address was ever on the list, because a form that answered that question would tell anyone who asked it. So if you send an address that was never signed up, the request itself creates the record it then deletes.
What is going to change
A privacy page that only describes today is half a page, because the honest risk is that something above quietly stops being true. Here is what we already know will move.
Teams will add accounts, recording and history
The plan described on /teams — session recording and playback, transcripts, code history, scorecards, a shared question library — is a plan to keep things that are thrown away today, on purpose. None of it is built and none of it is on sale, and this page will be rewritten before any of it ships rather than after.
Recording will be switched on by somebody, visibly
When it exists it will be a thing an interviewer turns on for a session, and everybody in the room will be able to see that it is on. What this page will not do is promise you that recording can never exist, because the roadmap above would turn that promise into a lie inside a year — what we will say instead is that it will not happen silently, and that a room with nobody recording it behaves exactly the way this page describes.
The free session stays what it is
Pasting a problem, generating and running the tests, the shared cursor, the video, a candidate who needs no account: those are free today and /teams commits to keeping them free. A plan for the interviewer’s side of the table is not going to start collecting more from the candidate’s side.