Midlight Privacy Policy

What is on Midlight’s server

Midlight keeps the canonical copy of your account and your work in its own PostgreSQL database, on a server Scott runs. That is what makes the same conversation appear on the next computer you sign into. It holds:

• Your account. The Google account identifier, the email address Google verified, and your name if Google supplied one. Nothing else Google offered is kept — the profile picture column was removed from the database, and the locale is never read. The interface draws your initials instead, so opening Midlight does not tell Google that you did.
• Your conversations. Every message, in full, and when it was sent.
• What you attach. Both the text Midlight extracted in order to read the file and the original bytes, so you can have the file back.
• Your folders and documents. Including pointers to files that live on your own computers — the pointer and where you filed it, never the file’s contents.
• Your computers. The name and platform each machine reports, and any folder you have lent Midlight on it.
• What Midlight has come to understand about you, where cross-chat memory is switched on for your account: dated, source-linked, correctable sentences, each one tied back to the message you said it in.
• A record of what each reply could see from outside its own conversation, so “how did you know that?” has an honest answer.

Your session is stored only as a hash. A copy of the database is not a set of working sign-ins.

Who else sees a conversation

Midlight does not run its own model. To answer you it sends the conversation to the model provider it has been configured with, and it sends the whole thread each turn, not just your newest message. That provider is the company that ends up reading it.

A conversation with a picture in it is answered end to end by a provider configured to see images — every turn, for as long as that conversation contains an image. That may be a different company from the one answering your text-only chats. If no configured model can see, Midlight refuses the picture before uploading it rather than failing quietly.

Provider credentials stay on Midlight’s server. The desktop application never holds one and never talks to a model provider directly.

Dictating into the composer

The composer’s microphone button is a separate capability from the rest of chat, and it asks before it does anything: the first click explains what is about to happen and asks the operating system for microphone permission. Nothing is sent anywhere until you say yes, saying no changes nothing else about Midlight, and that answer is remembered on this computer so you are not asked again.

Once you agree, a recording — and a small, bounded amount of the current draft and the most recent message in the conversation, never anything more — is sent through Midlight’s server to Groq, which turns the recording into text and cleans it up. Groq is the company that reads the audio and that text for this one request.

Midlight keeps no separate record of a dictation afterward. Midlight’s server holds the recording only for the length of that one request to Groq and discards it; no audio, no transcript and no record that a recording happened is written to a database, a log, or a diagnostics file, here or on your computer. Groq may briefly retain the audio and text it was sent under its own data policy. The text that comes back is inserted into your draft and is never sent on its own — from that point it is ordinary draft text, saved with the draft and part of the conversation’s own history if you send it.

Experimental system-wide dictation

Dictate anywhere is a separate, optional Windows experiment. It is off by default and Midlight explains what it does before you turn it on. While you hold its chosen key, Midlight records your voice and, when the focused text field exposes it, reads a small amount of nearby text plus the focused app and window to improve the words. Credential-shaped text is redacted.

The recording and that redacted context are sent through Midlight’s server to Groq. Raw audio stays on this computer for 30 days; transcript history and vocabulary learned from your own dictations stay until you delete them. “Delete dictation history” removes that raw audio, those transcripts, the learned vocabulary and interrupted-deletion residue for this account on this computer. It does not delete conversations or change the composer microphone’s separate consent.

What stays on your computer

• The offline copy. The desktop keeps a local database of your conversations so being on a bad connection is not the same as being logged out.
• Local work. When Midlight reads or changes a file on your machine, that happens on your machine. When it hands a question to a local Codex agent, that runs under your own Codex sign-in, in a read-only sandbox that blocks writes and network access, and Midlight stores no credential for it.
• What a read returned. The contents a local read produced belong to the reply that asked for it, and are released when the reply ends. A reply interrupted by a restart has what it borrowed let go of when the service comes back.
• The receipt keeps counts, not contents. “Read 11 files · Ran 3 local commands” is what is kept — categories, counts, how long it took, what authority it had, and how it ended. Never the commands, the paths, the file contents, or the prompt.
• The developer journal. The desktop keeps a bounded local diagnostics journal of event kinds and timings. It never contains payloads, secrets, file contents or reasoning, and it does not leave the computer.

Read-only is real, and it is also narrower than it sounds: Codex’s sandbox stops writes and the network, but it does not confine reads to the folder it started in. Midlight says so plainly in Settings rather than implying a boundary it does not enforce.

Two separate things decide whether this can happen at all, and only the second is yours. Delegating work to a local agent is a capability the operator switches on for this service, and can restrict to particular accounts; if it is not on for you, none of this happens at all. Where it is on and your computer has an agent ready — Codex installed and signed in — Midlight will use it by default, and Settings on that computer has the switch to turn it off. It is off wherever there is no ready agent, which is most computers.

Deleting

Deleting a conversation removes its messages, its attachments — both the extracted text and the original bytes — anything Midlight remembered from it, and the record of what any reply saw through it. What is left is a tombstone with no title in it, which exists only so your other computers know to erase their copies too.

There is no hidden thirty-day trash. If a reply was drawing on a conversation you delete while it is still being written, that reply is discarded rather than kept as a snapshot that can no longer be checked.

You can ask Midlight to forget one thing it remembers, in ordinary conversation, without deleting the chat it came from.

Signing in with Google

• Midlight asks Google for openid, email and profile, and nothing else.
• It asks for online access only and receives no refresh token. It needs to know who you are once, at sign-in, and has no reason to act as you at Google afterwards.
• The identity token is verified against Google’s published keys rather than trusted for having arrived on the right address.
• Where the Google token goes. Midlight’s server exchanges the sign-in code with Google and receives a short-lived identity token in the reply. It reads three things out of it — the account identifier, the verified address, and the name — and keeps nothing else: the token is never written to the database, never logged, and gone when the request ends. The desktop is not an OAuth client and never receives one at all; it receives a Midlight session. This website is not an OAuth client either and has no sign-in on it.

Being able to sign in with Google is not what gets you in. Invitations are rows in Midlight’s database, checked after Google has said who you are.

Connecting Pinterest

If you choose to connect Pinterest, Midlight may read information from your Pinterest account, including account details, boards and Pins, only to provide a feature or analysis you explicitly request.

• Read-only. Midlight requests read permissions and does not create, edit, delete or publish Pins or boards on your behalf.
• Used for your request. Pinterest information may be sent to the model provider involved in the analysis you requested, just like other material you ask Midlight to analyze. Midlight does not sell Pinterest data or use it for advertising.
• Revoking access and deletion. You can revoke Midlight’s Pinterest access through Pinterest, which prevents future Pinterest API requests. To ask Midlight to delete information retained from a Pinterest-powered experience, email [email protected].

Connecting Pinterest is not permission to use it for unrelated personalization or to act on Pinterest without a new request from you.

This website

midlight.ai is a handful of static files. Two of them run JavaScript: the front page, which draws the moving orb and sends the invite form, and the download page, which reads the operating system your browser already reports so it can mark the right installer. The download page collects nothing and sends nothing anywhere — it works the same with JavaScript switched off, and every installer on it is an ordinary link. The invite form is the one thing here that does send something, and it has a section of its own below. The site sets no cookies, uses no analytics or tracking product of any kind, and loads no fonts, scripts or images from any other host — everything it needs is served from this domain.

Your requests are still counted somewhere. Midlight’s own web server writes an ordinary access log — one line per request, including your IP address, as any web server does. This site is also reached through Cloudflare, which sits in front of it and terminates the connection, so every request passes through their machinery before it reaches Midlight’s. What Cloudflare keeps about it is theirs and described in their documentation, not something this page can promise on their behalf. Neither is something Midlight reads or does anything with, and neither is a cookie, an identifier, or a profile that follows you; but “nobody is counting” would not be true, so it is not what this page says.

The typefaces are Geist and Geist Mono, served from this domain and used under the SIL Open Font License 1.1. The copyright notice and licence are published here alongside them.

Asking for an invite

The form on the front page is the only thing on this site that sends anything anywhere. When you submit it, it posts what you typed to Midlight’s own server on this domain: the Google address you would sign in with, and — if you filled them in — what you would use Midlight for and which computers you would run it on. There is a fourth field in the page that is off the screen, out of the tab order and empty; it is there because something that arrives with it filled in was not a person.

A request that arrives waits in a pending queue until a person deals with it. What is stored there is what you typed and when it arrived, and nothing else: Midlight’s application deliberately keeps no IP address, no fingerprint, no analytics identifier, and no cookie with it — the page sets none and reads none. The answer is the same whether the address is new or has asked before, so the form cannot be used to find out who is already on the list.

What you would use Midlight for is context for that one decision, and it is kept only for as long as the decision is pending. When the request leaves the queue — accepted or declined — what you wrote is deleted with it, and it is not carried into the invitation list. A person can still write a note on an invitation by hand, which is the only way anything you wrote outlasts the queue.

There is a limit on how many people can be waiting at once. If the pending list is full, a request is turned away with a message asking you to try again later, rather than being accepted and quietly dropped, and you can send it again once there is room. That happens the same way for every address, because whether the list is full is settled before the server looks at who is asking: a full list is a fact about the list, not about you. The address itself is never named in the refusal, and nothing about it is stored on the way to being turned away.

That request is still a web request. Caddy’s access log and Cloudflare see it arrive, with your IP address in it, exactly as they see every other request to this site — what is said above about counting applies to this one too. “Midlight stores no IP address with your request” is a claim about Midlight’s application, not about the machinery underneath it, and this page is not going to blur the two.

If the request is accepted, the address becomes a row in the invitation list — the same rows that are checked once Google has said who you are. If it is declined, the request is deleted and nothing is kept in its place. There is no separate mailing list and the address is not used for anything else: Midlight hands it to no analytics product, no mailing tool, and no other company. The one thing your request does travel through is the ordinary infrastructure described just above, which is not somebody Midlight gave your address to.

Backups

Scott can take encrypted backups of the database. A backup includes the files and pictures people attached, which is one reason it is never written unencrypted.

What is not settled yet

This is a private beta with a small number of people in it, and some things a mature product would have promised are genuinely undecided: how long anything is kept after you stop using Midlight, how you would export everything, and what account recovery looks like. Those are open questions rather than quiet answers.

If your invitation is revoked, your sign-ins end immediately and your existing data is not deleted for you. Ask and it will be.

Asking

[email protected] reaches a person, and there are few enough people in this beta that it will be answered by one.