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 and profile picture if Google supplied them. Midlight’s server fetches the picture from Google once each time you sign in and keeps it with your account as a small image; the apps show that copy and never load it from Google, so opening Midlight does not tell Google that you did. Nothing else Google offered is kept, and the locale is never read.
• 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.

In the web app, unsent draft words, attachment pointers and messages waiting for a delivery answer stay in browser storage, separately for each account. Original unsent file bytes stay in IndexedDB so a reload or lost connection does not lose them. Sending or discarding releases file copies no longer needed; abandoned copies are cleaned up when the account next opens after their page closes. Explicitly signing out of the web app, or the browser learning that the account was deleted, removes that account’s drafts, pending messages, retained file bytes and browser key. Switching accounts or a temporary connection failure keeps unsent work recoverable. Other accounts’ browser storage is left alone.

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.

Reading replies aloud

Pressing the speaker below a reply can read its words aloud. Device voices use an installed speech engine. When a cloud voice is available and selected, those words go through Midlight's server to the configured speech provider: Google Gemini, ElevenLabs or Deepgram. Your other messages and files are not included in that request. Previewing a voice in Settings sends a fixed sample sentence to the same service, without sending a reply or changing your chosen voice.

Speech credentials stay on the server. Midlight does not store speech requests or audio in its account database or logs. The app keeps a limited audio cache in memory while the chat is open and clears it when you leave. The speech provider handles the words and audio under its own data policy. Gemini requests disable stored interaction history. You can choose Device voice in Read aloud settings to avoid cloud speech requests.

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.

On the Android app, the microphone records inside Midlight, so dictation keeps going with the screen off; a “Dictating” notification with Stop shows while it listens. The recording stays on the phone only until its words are written, then it is deleted. Choosing This phone in Account → Dictation has Android’s own speech recognition write the words instead: on the phone when it has an on-device model, otherwise Android may use Google’s online recognition. Nothing is then sent to Midlight or Groq.

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. During the private beta a separate allowlisted projection of errors and sampled timings is shared with Sentry unless you turn it off, as described below. The local journal is not uploaded.

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.

Usage and diagnostics

Desktop Midlight and the iOS and Android phone apps share scrubbed errors/crashes and supported performance diagnostics with Sentry to help fix problems. This is on by default everywhere, including the EU and UK, for new installs and existing installs where no choice was saved. An earlier saved off stays off. A brief first-run notice explains this and offers Turn off and OK buttons. Reports can queue locally, but nothing is sent until you acknowledge that notice. Headless/CLI installs stay off when no choice is saved. In Settings › Diagnostics, Automatically share diagnostics is the switch that turns it off anytime. Turning it off immediately purges queued automatic reports and stops an in-flight request where it can. It cannot recall a report Sentry has already accepted. The local journal carries on as before. Builds without a configured reporting destination send nothing. This desktop default does not change the phone apps’ separate diagnostics choices.

Sentry, our error-tracking service, stores these reports in the United States. Sentry keeps accepted diagnostic events for 30 days. Sentry does not store IP addresses for these reports. Midlight does not attach an IP address or user location to diagnostic events; Sentry’s privacy settings also filter connection-derived geography. A network connection still exposes its source IP to the service while it is handled.

Automatic reports contain only allowlisted technical error types, scrubbed app stack locations, app version/build, platform, capture time, random event identifiers and fixed failure categories. Native panic reports may include addresses within Midlight’s own executable and symbol identifiers. Desktop timings describe selected send, conversation render and startup boundaries; 5% are sampled at operation start, with at most 12 admitted timing records per hour. On phones, a small sample describes connection attempts, resume probes, time to reconnect and send acceptance. Durations are bucketed; ordinary observations are sampled at 1%, while failures and slow observations take priority. Each phone admits at most 5 timing requests per day and 75 per rolling 30 days, with no timing payload retry queue. The phone notice describes these timings before sending. When a desktop agent turn or background process stops making progress, or a command reaches its time limit, desktop Midlight can send a stall event: the agent provider, a model family (such as “opus” or “gpt”), the kind of tool that was running (such as a command or a subagent), bucketed durations and whether it was still running, stopped or failed. It never includes what the agent was doing, commands, paths, output or chat identifiers, and is limited to two requests a day. Each install sends a random, locally generated anonymous install ID so we can count affected installs. It is not tied to a person or account, hardware, advertising identifier or profile. It normally stays the same across restarts, resets when sharing is turned off, and a new ID is used if sharing is turned on again. Android also changes it after an app update. Recovering damaged delivery history on desktop or Android also creates a fresh ID. Reports contain no account, hardware device, Workspace or chat identifiers. The raw developer journal is not sent.

Automatic sharing excludes conversation text, message bodies, drafts, titles, prompts, tool arguments or output, file contents, audio, agent reasoning, account details, personal paths and credentials of any kind — passwords, tokens, cookies or authorization headers. There are no automatic screenshots, memory dumps or raw log uploads. Outbound payloads are reconstructed from strict allowlists; existing scrubbing and storage caps still apply.

On macOS and Windows, desktop diagnostics also record newly observed native dialogs to help reduce interruptions. Reports contain fixed dialog-host categories, detection coverage, whether Midlight processes are active, and whether the dialog's process can be linked to a Midlight-started process tree. They contain no dialog text, screenshots, window titles, process names, paths or process identifiers. System-hosted prompts may not reveal which app requested them; those remain unattributed. Detection uses existing permissions and never asks for new ones. Coverage is partial: short-lived or custom dialogs and secure desktops may be missed. At most 20 popup-report requests, including retries, are sent per rolling 24 hours, independently of crash and error quotas. With existing Accessibility access on macOS, Midlight also checks a focused system prompt’s text in memory to recognize a request for Midlight to read another app’s data. That text is discarded; it is never logged or sent. A quiet notice explains the choice and can open Full Disk Access settings. The access check opens a protected permission file without reading its contents or requesting a permission.

Delivery is best effort through bounded queues on this computer: automatic runtime reports retain at most 128 events / 1 MiB, and native reports at most 64 events / 64 KiB each, for up to seven days. Retries retain the original sharing generation; turning sharing off and back on cannot promote older local evidence or previously purged reports into sharing.

Report a problem is separate. In the report form, you review the description, optional image and technical context before explicitly sending them. Reports that include chat, usage or Memory and instruction context add your signed-in account email, shown in the preview. Reports with none of those parts do not add it. Turning automatic sharing off does not cancel a problem report you explicitly send; saving or exporting a report locally never sends it automatically.

You can also ask your chat agent to report a Midlight problem for you. The agent investigates, then asks before sending and says what it will include: by default, this chat, recent usage and Memory/instructions while transcript reporting is enabled. Only after you clearly agree in the conversation does it send the report directly, without a form. You can ask to leave parts out. The chat shows a receipt with View what was sent, which opens the stored report read-only, and Retry if delivery fails. The same account-email, redaction, retention and transcript-switch rules below apply. After acknowledgment, transcript payloads are removed from the local report store.

From a chat, you can choose Include this chat before sending a problem report. While available, this option starts checked. It sends messages, recorded thinking, tool arguments and output, errors and worker results to Scott/Midlight through Sentry, alongside attachment names and a snapshot of your setup: the chat’s folder path, provider versions, account kinds, settings, recent local diagnostics and your signed-in Midlight account email, so Scott knows who hit the problem. Reports that include a chat are linked to your account email, which is also sent as Sentry's feedback contact email. File attachments are not opened for the report. Your computer’s name is included only if you choose it. The preview shows the payload and any truncation. You can review it or uncheck inclusion before sending. Recognizable credentials are removed; please still review the chat for anything private. Sentry keeps these reports for 30 days, with IP and location storage disabled. You can uncheck chat inclusion before sending. Midlight can also turn it off for everyone, removing unsent transcript attachments at the next check. If that check is unreachable, pending transcripts stay local and wait for permission to send. Delivered transcript payloads are removed from this computer's report store. Reports already accepted by Sentry cannot be recalled by the switch; ask us to delete one using its report code. Account deletion does not automatically delete these reports from Sentry.

Two separate choices also start checked while this reporting feature is available. Include usage from the last 5 hours adds provider allowance windows and the titles, models, effort, times, tokens and cache use of chats, workers and background work on this computer. It works even if you untick the chat; it does not add other chats’ messages or tool output. Missing readings are shown as unknown. These optional reports also include your signed-in Midlight account email.

Include Memory and instruction files includes personal notes: the Memory map, stored output from Memory files read in the selected chat, applicable instruction files, selected skill names, configured hook commands, and the context Midlight added to captured turns. Contents are stored once per distinct hash in the report, within size limits. The preview warns that personal notes are included; you can untick this choice. Unticked, Memory file operations and search results are filtered, and added context includes only sizes and hashes. An agent’s quoted prose cannot be filtered reliably. Older turns may lack exact injected context; current instruction files are a snapshot when you make the report. The same remote switch removes all these optional parts from unsent reports and purges their local capture tables at the next explicit off check. Local capture stops until the switch can confirm it is on. Captured contents are bounded to 4 MiB, with at most 512 recent turn/worker evidence records (32 KiB each); older evidence may be unavailable. Naming and background capture keeps at most 2,048 records for eight days.

Deleting

You can delete your whole account, in the app or by email. That deletes everything the account keeps on Midlight’s server — its Workspaces, Projects, Memory, Work, kept chats and attachments, and its computers, phones and browsers — and signs out every computer and phone. No computer is wiped from afar: each keeps what Midlight has on it unless you choose to erase it, and nothing from it goes into a new account without your say. A random identifier for the deleted account is kept for 180 days, and copies in Midlight’s encrypted database backups are removed as those are rotated out, on a schedule that keeps about eight weeks of them. How to delete your account, and exactly what is kept.

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 four things out of it — the account identifier, the verified address, the name, and the address of the profile picture, which it downloads once, only from Google’s own picture host — 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 hello@midlight.ai.

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

The Midlight Chrome extension

The Midlight extension lets Midlight, running on your computer, use your Chrome when you ask it to: open pages, read them, take pictures of them, click and type. It does nothing on its own, and it only works while Midlight is running on the same computer.

• Which tabs. It works in the windows Midlight opens for a chat, and in a tab of yours only after you hand that tab over. It doesn’t read or watch your other tabs. To offer a tab to hand over, Midlight can see the titles and addresses of your open tabs.
• The side panel. Midlight’s side panel in Chrome is your Midlight chat. It shows the title and address of the tab you’re on, and reads that page (its address, title, selected text and text) only when you send a message with the page attached. That page goes with your message, and is kept with the chat like text you paste.
• Where page data goes. Everything the extension reads goes to Midlight on the same computer, through Chrome’s connection to apps installed on it. The extension sends nothing to Midlight’s server or anyone else, and has no analytics (the one exception, signing in from another device, is below). Midlight then gives what was read to the AI provider running that chat (such as Anthropic or OpenAI), as part of the work you asked for, under that provider’s terms.
• What is kept. Screenshots the agent takes are kept with the chat on your computer, like attachments. Midlight’s records of the chat leave out the page text the agent read (a page you send from the side panel is part of your message); what the agent writes in its reply is kept like any other message. Midlight’s local browser log keeps which actions ran, website origins and timings, never page text, form values, screenshots, cookies or full addresses.
• Watching from another device. When you watch Midlight’s Chrome window from your other computers, pictures of that window pass through Midlight’s relay to your own signed-in devices. They aren’t stored.
• Signing in from another device. When an agent needs you to sign in to a site and you answer from your phone or another computer, the extension shows you that one Midlight tab there, and your taps and keys go back to it. The picture goes from Chrome to your device over an encrypted connection your own Midlight devices set up; when there’s no direct path it passes through a relay that can’t read it. It isn’t stored, and it ends when you finish or leave.
• Downloads. While Midlight is working in any tab, the extension tells Midlight about every download in that Chrome profile, with its address and file name, because Chrome doesn’t say which tab started it. Midlight keeps the ones its own pages started (it can put the file in the chat’s folder or cancel it) and ignores the rest.
• In Chrome itself the extension keeps a random identifier for the Chrome profile, whether you disconnected it, when it last connected and when to try again, and, for Midlight’s own windows, which chat each belongs to, its window and tab numbers and where it sits, so it can find them after Chrome restarts; for the side panel, which chat each window shows and the Workspace you picked. No page addresses or content.
• Your choices. Settings → Browser decides, for each Workspace, whether agents may use Chrome, on which sites, and when they must ask first. Midlight never types passwords; signing in is left to you. Choose Disconnect in the side panel’s Connection sheet, or remove it from Chrome, to stop it entirely.

Data the extension handles is used only to do what you asked. It is not sold, not used for advertising, not used to judge creditworthiness, and not given to anyone else except the AI provider doing the work, as described above.

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 account server, at midlight.ai/api 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. To slow down scripts, the server counts recent requests from each IP address for a few minutes, in memory only; that count is never written down. The answer is the same whether the address is new, has asked before or is already invited, so the form cannot be used to find out who is already on the list.

When a new request arrives, Midlight sends Scott an email, through the Resend email service, saying only how many requests are waiting: never your address or anything you wrote.

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, which keeps only the address it was made for.

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. Cloudflare sees it arrive, with your IP address in it, exactly as it sees 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

Midlight's database is backed up every hour, always encrypted, and older backups are rotated out on a schedule that keeps about eight weeks of them. A backup holds what the database holds, which can include text extracted from attachments; the attached files and pictures themselves are kept in Midlight's file storage, not in these backups.

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

hello@midlight.ai reaches a person, and there are few enough people in this beta that it will be answered by one.