Privacy

Last updated: 7 October 2026

Luke is a macOS app for planning a feature by voice. This policy explains what we collect, who we send it to, and how to turn it off.

What we collect

On your Mac. Luke reads no coding agent session on your Mac, and nothing on it reads message history, file contents, or command output, beyond the read-only commands the planning model asks for in a plan's folder, described under "How the planning model reads your folder" below. The Mac app lists no coding agent sessions; what our service still does with a Conductor key an earlier version synced is described under "Scheduled observation of your Conductor sessions" below, and none of it runs here. No part of Luke's judgment runs on this Mac, so no transcript, working memory, or inbox of his is held here, in memory or on disk.

Your conversation with Luke. Nothing on your Mac holds your conversation with Luke: no part of his judgment runs here, so no record of what you said, what he spoke or announced, or what he did at your ask is kept on this machine, in memory or on disk, and the Mac app does not read that record back. A voice session on this Mac is a call about one plan, and it opens with nothing of your coding agent sessions and no line of your conversation, from here or from our service; what Luke knows when he answers a spoken ask he reads on our service, from the plan and the record described under "Your account" below. What our servers keep of a conversation is the record described under "Your account" below; a fixture or evidence run keeps no conversation at all.

Conversations Luke opens for himself. In a turn of his own on our service — in his conversation with you, or in the conversation of his that follows one of your sessions — Luke may hand part of the work to a helper: a child conversation opened beside the one he is working in, run by the same judgment under your account, and never on your Mac. The child can read what its parent can read — your Conductor sessions as our service last observed them, and a chat's conversation, your own messages and the agent's replies, not its tool activity, under the same synced key — and do what its parent can do: the actions on your coding agent sessions, the writes to his workspace files and the dated notes, and the search and reading of his notebook. It cannot speak to you or announce anything, and it cannot open a child of its own. When it finishes, its final reply is handed back to the parent as one turn there, unless the parent asked for none, and the parent decides what, if anything, you hear of it. What the child said and each tool it called, with its input and its result, is stored as a conversation of your account, in the same rows described under "Your account" below and on the same terms: stored as written and readable by our own operators, and removed at once when you delete your account. A child of your own conversation is marked deleted with the rest when you clear the conversation and removed thirty days later; a child opened from a conversation Luke follows stands with the conversation it was opened from, which Clear does not reach, until you delete your account. Each of its turns counts against your daily review allowance like any turn of Luke's own.

Luke's workspace. Luke's workspace is a small set of Markdown files — his operating instructions, his identity, stable facts about you, curated notes, first-run setup notes, and dated notes — kept as rows in our database, one row per file per account: seeded with the same defaults the first time a turn runs for you, composed into the standing instructions every turn runs under (each cut to 20,000 characters, the stable facts about you and the curated notes to 4,000 each, and the set to 60,000), and edited only through Luke's own workspace tools there, in his turns and in the one housekeeping call described under "How Luke keeps his notebook" below, which refuse a file past its bound rather than cut it, so the file he reads is the file that exists. The file's name and its contents are stored as written, bound to your account and readable by our own operators, the same way the conversation described below is. Those rows are untouched by clearing the conversation and are removed when you delete your account. Earlier versions of Luke kept the same files on your Mac, under his application data (agents/main/workspace), and read them into the calls they made from here; this version makes no such call, seeds nothing there, and reads nothing from it. Files an earlier version left are yours to keep or delete, and nothing on your Mac reads or writes them.

Feature plans. When you start a named plan, our service stores it under your account: its name and the plan's one document, a Markdown body and a list of assumptions, written by the planning call's notetaker as you talk. It is stored as written, bound to your account and readable by our own operators, the same way the conversation described below is. A save replaces the document and no earlier version is kept; deleting a plan removes it at once, and deleting your account removes every plan.

How the planning model reads your folder. While a plan is open in Luke on your Mac, Luke's planning model, which runs on our service, can ask your Mac to run a shell command (such as ls, grep, or cat) in the plan's folder. Luke on your Mac runs each command with the folder as its working directory, inside a macOS sandbox that blocks all network access and all writes, and lets the command read only that folder and the system's own programs. A file named .env or starting with .env is not read, even in the folder. None of Luke's own environment reaches the command. Luke sends the command's exit code and up to 20,000 characters each of its output and error text back to our service, which hands them to the planning model. No copy of the folder is made, and the folder's path stays on your Mac: our service never stores it. Each command and its output are stored with the plan, and with the plan's planning conversation, under the terms described for each; deleting the plan deletes its commands.

Luke's working memory. Luke's judgment keeps a working memory of its own turns — the model's record of what he read, said, and did, folded into a written summary of his own when it grows long — and it is kept where his judgment runs, on our service, under the terms described under "Your account" below. Nothing of it is held on your Mac, in memory or on disk: a launch here begins with none and a quit lets nothing go, because there was nothing here.

Earlier versions of Luke kept the conversation, his working memory, the things he remembers about you, and a search index over his workspace files in a database under Luke's own application data, in a folder of its own per agent (agents/main/agent.sqlite, with recovery archives beside it under archives/), and versions before those kept them in three files beside your settings. This version composes no judgment on your Mac at all and reads and writes none of them, so that conversation, that memory, and those remembered things start over on our service. Each launch removes the database and its recovery archives if it finds them; the three older files stay where they are until you remove them.

Luke's runtime runs inside the app, and can run on a server you connect to instead; either way it holds your settings and the encrypted credentials (decrypted where it runs, under the same Keychain entry) and your account's session, while the part that draws listens, speaks, holds the keys, and asks the runtime for everything else. Nothing about you crosses that boundary that the panel did not already draw; no stored key, token, or account secret travels in any answer or event, and the voice window is handed no credential at all — the runtime opens each voice session itself and hands the window only the connection answer it needs to hear and be heard. Quitting Luke cancels what was running and writes down what did not finish rather than finishing it on paper. The one thing the app still does on this machine at the runtime's ask is opening an address you asked to open.

Things Luke remembers about you. When Luke runs a turn for you on our service, he may record a concise preference, personal fact, goal, or recurring constraint that looks useful later, as a dated line in USER.md, one of the workspace files described above. He skips temporary details and uncertain guesses, never records credentials, and records sensitive facts only when you explicitly ask. USER.md is a workspace row like the others: stored as written, bound to your account, edited only by Luke's own workspace tool in his turns there, untouched by clearing the conversation, and removed when you delete your account. A line a newer one replaces is marked superseded rather than silently dropped, so what he knew and since when is on the page for you to read. Nothing on your Mac saves or reads one: an earlier version kept them as lines of a USER.md in the workspace it held here, and a USER.md that version left is neither read nor written by this one; a version between kept them as database rows of their own, and this one keeps no such rows. You can ask Luke what he remembers, correct something, or tell him to forget it. The file travels with the rest of Luke's working memory when he thinks on our service, so he can personalize replies, on the same terms as the rest of that call — one model call per request, and nothing of it stored or logged by our service beyond the row itself. It is never sent to a coding-agent provider or a tracker, and it is never used to decide anything on your behalf.

Luke's notebook index. Luke keeps no standing search index over his workspace files. When Luke, thinking on our service, searches his notebook (his memory_search tool), the service reads your workspace rows there — MEMORY.md, USER.md, and the notes under memory/ — cuts them into passages, and asks OpenAI's embeddings model, under Luke's own key, for a numeric embedding of each passage it has not embedded before and of the search itself; it ranks the passages in that same request and keeps only a hash of each passage and its embedding, never the passage's words, dropping the embeddings of passages your files no longer hold. A deployment without that key searches by keywords alone, and Luke says so when it did. His memory_get tool reads an excerpt of one of those same files by line range and nothing outside them. Nothing on your Mac makes an embedding, and Luke's own conversations are never embedded or indexed.

How Luke keeps his notebook. Nothing on your Mac writes Luke's notebook: no housekeeping turn runs here, no nightly job reads your conversations to learn from them, and no model call on this machine rewrites MEMORY.md. The notebook Luke keeps is the workspace rows on our service, described above, written through his own workspace tools in his turns there, and by one more call beside those turns: before Luke's working memory of a conversation is folded into its summary (described under "Luke's working memory" above), one bounded housekeeping call on our service reads a private copy of that conversation as data and may append what is durable in it — a decision, a result, something learned — to the dated note for the day, memory/YYYY-MM-DD.md, in the same workspace rows, through the same append his turns use; it can write nothing else, and appends rather than rewrites. It runs only while you are asking Luke something yourself, typed or spoken, never in a turn the scheduled observation opened; at most once each time the memory folds; on the same model and under the same daily allowance as his turns; and within a minute, or not at all. Nothing it reads or says appears in the conversation, on any device, or in a notification: what the conversation's row keeps is that the call ran, when, and how it ended (it stored something, found nothing to store, was skipped, was cut short, or failed), never a word of it. A call that fails changes nothing and Luke's answer to you proceeds as if it had not been asked. An earlier version of Luke wrote a dated note under memory/ and promoted lines into MEMORY.md behind HTML markers on your Mac, and wrote a DREAMS.md beside it; each is left exactly where it is, for you to keep or delete, and nothing reads any of them. Asking Luke to forget removes the line you name from his USER.md on our service; a thing he never wrote down he says so about rather than claiming it erased. Forgetting does not delete the conversation itself.

How the plan is written during a planning call. While you talk a plan through with Luke on a planning call, a notetaker on our service writes the plan document; Luke's own judgment no longer does. Once you have been quiet for about a second, it makes one call to OpenAI (gpt-5.6-luna) on our key, carrying the plan as it is saved, both sides of what was said since its last note with a few lines before them, and the words of Luke's own replies, and saves the fields that call answers into that one plan. It runs only during a planning call you started and only for that call's plan, each run counts against the same daily allowance as Luke's turns, and a run the allowance refuses, or that fails, writes nothing. Nothing it reads or answers is kept beyond the saved plan, said aloud, or shown anywhere but the plan itself, and OpenAI keeps the request and its reply under its own retention policy.

Your account. Signing in with Google or GitHub gives us your name, email address, and which of the two you used. Signing in with GitHub grants no access to your repositories: plans read a folder on your Mac instead. An account that signed in with GitHub before this may still hold GitHub's repo permission, which Luke no longer uses; you can revoke it at any time in GitHub's settings under Applications. We also keep the records that keep you signed in, and a daily count of how much voice and review you have used. Luke's own maintainers can see that record — your name, email address, which sign-in you used, when you joined, when you were last active, and your daily counts — on an admin page of our site that only an account we have marked as an administrator can open; nothing you type, say, or run in a session appears on it. The service also keeps your account's conversation with Luke. When Luke runs a turn for you on our service, that turn writes rows to our database: your ask as it was given; Luke's reply, the summaries of his reasoning, and each tool he called with its input and its result, the briefing he offered you among them; the words an observation turn opened with, which for a Conductor session include the messages that chat gained since he last looked; the turn's model, token counts, and the ids of OpenAI's responses; and the events about each message — that a briefing was offered, claimed, spoken, pushed, or expired, and each rating you gave or took back — naming the device that took part. When you speak with Luke through your account, what you said is kept as your line and what his voice said as his — an answer he gave without running a turn, what he said before and after one, a briefing or a reply he read aloud — each written once it has settled, so the Conversation shows the words you actually heard beside the turns he ran and the messages he read from. Like his workspace files, the things he remembers about you among them, these rows are not sealed: they are stored as written, and our own operators can read them. They stand until you clear the conversation, which marks it deleted so that every device stops drawing it at its next read and the service removes it thirty days later, or until you delete your account, which removes it at once.

Usage data. We count how Luke's features are used on the Mac, and attach your name and email to that record. The counts are event names and values from a fixed list. A voice session's start is counted with the source that opened it, our voice service on your account, and never with a session id. A count made before you sign in is not sent. Nothing you type or say and nothing from a session can appear in one: no titles, branches, file paths, prompts, or error text.

Screen recordings. Luke records what his own panel draws, and never your screen, your editor, your terminal, or any other app. The recording is the shape of the panel, not its words: before it leaves your Mac, every piece of text the panel shows is replaced with blocks of the same length, so a plan's name and its document, a caption of what you or Luke said, your name and email address, and anything you type into a field all appear as blocks. A screenshot you attach to the feedback form is left out, since a picture of your screen could carry another app's words, and so is the feedback form's message field, as a second line. Luke does not report what you clicked.

Recording starts when Luke opens, before you sign in, so it covers the signed-out panel and the sign-in. A recording that begins before you sign in is attached to your account if you sign in while it is running. One that never reaches a sign-in belongs to nobody, so deleting your account does not reach it — we have no way to tell it was yours.

Crash reports. In ordinary runs, Luke sends Sentry anonymous reports of unhandled exceptions in its Electron main, preload, and renderer code, along with anonymous process-session status and native minidumps when an Electron main, renderer, or GPU process crashes. Sentry's default reports include the exception message and code path, breadcrumbs, and Electron, operating-system, runtime, and device context. Luke does not attach your Luke account or user identity, and does not enable PII collection, tracing, Sentry Replay, screenshots, profiling, or manual reports of handled errors. Fixture and evidence runs send no crash reports.

Provider API keys (server-side vault). Earlier versions of the Mac app let you enter a Conductor key, which they sent to our vault under your signed-in account; this version neither asks for one nor shows one, and sends no key anywhere. A key or a calendar grant an earlier version kept encrypted on this Mac stays in its settings file as that version left it, still encrypted: this version neither reads nor sends it. We store a synced key encrypted in our own database using AES-256-GCM with a server-only secret. It is never returned to any caller: there is no endpoint that reads it back, and no code path that decrypts it for any purpose other than observing your sessions or carrying the actions you explicitly request through that provider. Every key is deleted alongside your account if you delete that. Voice holds no key of yours at all: it runs through our service on your account, and a key of your own that an earlier version of Luke stored for it is removed from your Mac the next time Luke opens, without being read.

Scheduled observation of your Conductor sessions. While you hold a synced Conductor key and have signed in within the last 7 days, our service reads your Conductor sessions on its own schedule, about once a minute, in a read-only pass: your open workspaces, their chats, each chat's status, the agent kind running it, and the error line it stopped on. It never reads a chat's messages. Beside that pass, and only for the chats it listed, our service works out which of those chats changed since it last asked from the last-updated instant that same pass read of each chat's status; nothing further is asked of Conductor for it, and it carries no message either. A chat that gained messages wakes Luke's judgment for that chat, on our service; that turn reads what the chat's conversation gained since he last looked — your own messages and the agent's replies, not its tool activity, cut from the front to 20,000 characters — under the same synced key, and hands them to Luke as one line per message under the speaker's name, alongside the chat's title, workspace, and provider from the stored roster. A chat that gained only tool activity wakes nothing. We keep the latest roster the pass read, encrypted at rest with the same server-only secret as your keys, so an earlier version of the Mac app can show your sessions without asking Conductor again; beside it we keep one instant per account, the point up to which Luke has been told of your chats' changes, and one position per chat marking where his last read of it ended. The roster is replaced on every pass; nothing older is kept. The conversation Luke keeps for a chat he has been told about stands while Conductor lists that chat; once a pass no longer lists it, because you archived or deleted the chat or its workspace, that conversation is retired, shown on no device from then on, and deleted 30 days later by the same purge that follows Clear. A chat listed again gets a fresh conversation. Observation stops, and the stored roster, the instant, and the positions are deleted, when you delete the synced key, when you have not signed in for 7 days, and alongside your account if you delete that.

Devices. This version of the Mac app registers no device row and reports no presence. When you signed in on an earlier version of the Mac app, the iOS app, or the Apple Watch app, that installation registered itself with our service as one device row, as follows. The row holds which platform it is, when it was last seen (refreshed by every poll and heartbeat: on a timer by an earlier Mac app, each time the phone comes to the foreground, and by the phone's and the watch's Conversation screens while they are open), an optional push token, and two instants: a presence instant and a quiet-until instant. An earlier Mac app reports both about once a minute: presence set only while your Mac has seen input in the last two minutes and its screen is unlocked, and quiet-until as an instant that holds Luke quiet while that version's own meeting or announcement switches hold him, moved forward by each poll so it lifts on its own if the Mac stops polling. The phone and the watch each report a presence instant too, on the poll their Conversation screen makes every few seconds while it is on screen and the app is in the foreground, each holding for thirty seconds; neither observes a meeting, so neither reports a quiet instant. Each is an instant and nothing else — not what you typed, not which app you were in, not the meeting's title, which never reaches the Mac either — and the service records them and decides nothing from them beyond holding speech while a quiet instant stands (a briefing already on offer is neither spoken nor pushed until it lapses, and a scheduled turn that starts under it is not given the tool that decides a briefing, so none is made to wait) and, for a Mac alone, waiting before it pushes a briefing, as described next: a phone or watch that is merely present is pushed to rather than waited on, since neither opens a call of its own for a briefing — though a call you have already placed on either says the briefings that arrive while it stands. The installation is named by an id the app made up once for itself; it is not a credential, and neither is a push token, which only our own Apple key can address. Signing into a different account on the same device moves its one row to that account rather than leaving a second. The row is deleted when you sign out on the device that made it, when the phone and the watch part ways with the account, when Apple reports a push token gone, and alongside your account if you delete that; a row an earlier Mac app made is not deleted by signing out of this version.

Briefing notifications. When Luke decides to tell you something about your sessions and no device of yours is placed to say it — no Mac of yours reports itself active, or the active one has not taken the briefing within two minutes; a phone or watch reporting itself present does not count, since neither opens a call of its own to say it — our service sends the briefing to the device of yours most recently seen holding a push token, as a push notification through Apple's push notification service, addressed to the push token that device registered. A briefing that arrives while a call of yours is standing on a phone or a watch is said in that call, under the same one-claim rule the Mac's call follows, and is never pushed; a phone or watch that is merely present, with no call standing, is pushed to at once rather than waited on. The notification carries Luke's own words, the briefing exactly as he chose to say it, and one identifier of our own: the briefing's message id, an opaque identifier unique to that one message, which is what lets a tap open the Conversation at that briefing rather than at whichever arrived last. It carries nothing else: no session title, branch, path, or error line beyond what those words themselves contain, and the id names none of them and means nothing to anyone but Luke. It is shown on the lock screen, so it is readable on a locked phone without unlocking it, and Apple carries it under its own terms on the way. A briefing is pushed at most once; one a device is already saying is never pushed; and while any of your devices reports a quiet-until instant, nothing is pushed until it lifts. Because a device's row moves with its sign-in, no briefing for the account you left is addressed to that device afterwards; one already handed to Apple at the moment you switched still arrives on its lock screen, and nothing we send can stop its display. That is the one window in which a briefing can reach a device signed in as someone else, and it holds only a briefing no device of the account had claimed. The iOS app asks for notification permission in the system's own dialog at its first launch, before you sign in; it asks Apple for a push token only where you allowed it, holds that token on the phone until a sign-in lands, and registers it with our service only while alerts stay allowed: a permission you later withdraw in Settings clears the token from your device row the next time the app comes to the foreground, so no briefing is settled as pushed to a phone that would show nothing. Tapping the notification opens the app's Conversation screen at that briefing; on a phone that has since signed out it opens nothing but the sign-in screen, and where the briefing is no longer in the thread the Conversation opens at its end and says so.

Feedback. If you use the feedback form, we receive what you typed, the name and email you signed it with, and any screenshots you attached; they reach us only when you press Send.

Who we send it to

  • OpenAI, for voice and for Luke's own judgment. A voice session is one continuous conversation: while you hold the talk key on your Mac, everything the microphone hears streams to OpenAI, and the moment you let go nothing does, the microphone closing; Luke can still speak into a session whose microphone is closed. There is no way to type to Luke; every ask is spoken. A Mac's session is a call about one plan, and opens with nothing of your coding agents. What you say and what Luke says in a call is written to your account's Conversation by our service, as described under "Your account" above, and kept nowhere on your Mac. When you use voice through your Luke account, your Mac reaches OpenAI through our own voice service, which creates the session on our key, relays the control and transcript events between your device and OpenAI, reads them on our side to keep the record and to hand each spoken ask to Luke's judgment (no device of yours answers a spoken ask itself), drops the audio OpenAI reflects back so neither your voice nor Luke's transits our service, keeps of the exchange only the lines described under "Your account" above, logs only status codes and byte counts, and records the billed seconds of each session once. Every voice session is opened this way, through our service on your account: nothing on your Mac holds or is handed a credential for OpenAI, and your Mac never reaches OpenAI on a key of your own. No session opens on its own: a call opens only when you press the talk key or the microphone on a plan. Luke's judgment is a separate call to OpenAI's Responses API, made from our service when a scheduled pass wakes the conversation following that session and when you ask him something: it carries that conversation's working memory — the bounded transcript excerpts described above, the session fields, the conversation so far, and his workspace files, the things he remembers about you among them — on our key. No such call is made from your Mac: it composes no instructions, offers no tools, and holds no record the reply joins; the record is the conversation our service keeps, described under "Your account" above. OpenAI stores the request and its reply under its own retention policy, and our service performs one model call per request and stores and logs none of the request, the reply, or the encrypted reasoning that travels in it. Each call counts against your daily review allowance. Every such call also carries a prompt cache key: a hash of the conversation's own internal name, sent so a later call reuses the earlier calls' billing prefix instead of paying for it again. It identifies nothing — no session id or title can be read out of a hash — and our service passes it upstream and keeps it no longer than the request. The same allowance meters a request to count a call's tokens or to fold Luke's working memory, and each note the planning notetaker writes. A development build run from a checkout can write a local trace of this traffic when the developer's own shell asks for one; a packaged build has no such switch and writes none.
  • Coding agent providers you connected in an earlier version (Conductor), using the key you supplied. The vault holds Conductor keys only. Luke reads your sessions, and sends something back only when you ask it to, such as a message you wrote. With a Conductor key in the vault, our service also reads your Conductor sessions about once a minute on the schedule described above, under that key. The observation turn our service runs when a chat's status changes reads what that chat gained from Conductor, under the synced key, as described under "Scheduled observation of your Conductor sessions"; nothing on your Mac reads a Conductor chat's messages. A message or a workspace Luke sends to a Conductor session at your ask travels the same way, admitted by our service against the sessions it last showed you.
  • PostHog, for usage data and screen recordings, from the Mac app. The counts go through our own service; the recordings go from Luke to PostHog directly.
  • Apple, for briefing notifications. When no device of yours is placed to say a briefing, our service hands Luke's words to Apple's push notification service, addressed to the push token your device registered, and Apple delivers them to the lock screen, where they are readable without unlocking. The notification carries those words and the briefing's own opaque message id, and nothing else about you or your sessions.
  • Sentry, for the anonymous exception, process-session, and native crash reports described above.
  • GitHub, to check for updates. These requests are unauthenticated and carry nothing about you.

We do not sell your information or use it for advertising. If you connect nothing, Luke sends nothing to any provider.

Our website

tryluke.dev counts page views, presses, and sign-in steps using PostHog, and records the pages themselves. Anything you type is blurred, and so is the text of whatever you clicked. Your browser contacts PostHog directly, so PostHog sees your network address, as it does for the app's recordings.

Storage

Your settings and your account's sign-in tokens stay on your Mac, the tokens encrypted under a key held in the macOS Keychain, beside whatever settings, keys, or calendar grants an earlier version kept there, which stay as they were but for a voice key, removed as described above. Nothing of your conversation with Luke, his working memory, or his workspace is kept on your Mac. A Conductor key you synced, and the latest roster of your Conductor sessions with what changed since the pass before, are stored encrypted in our own database and nowhere on your Mac, as described above. When Luke runs a turn for you on our service, the workspace files that turn reads and writes, the things he remembers about you among them, and the conversation it writes are stored unsealed in the same database, each as described above. Your account information is held by our own service, usage counts and recordings by PostHog, and crash reports by Sentry.

Your choices

  • Sign out of your Luke account to turn voice off.
  • A Conductor key you synced from an earlier version is deleted from our vault when you delete your account.
  • Ask Luke what he remembers, correct a memory, or tell him to forget one.
  • Delete any workspace file an earlier version of Luke left on your Mac; nothing reads it now. Luke's workspace rows on our service are edited through Luke alone, and go with your account.
  • Luke may act on his own judgment in a turn you did not open — answering a coding agent, keeping his notes, on a look — within the tool policy his configuration sets; his conversation records such an action as his own, never as your request.
  • What you type or say to Luke goes to his main conversation; the conversation an ask is for is fixed at the moment you send it and never moved afterwards.
  • Luke does not listen through your microphone except while you hold the talk key. The press opens the microphone and letting go closes it, so macOS's microphone indicator is lit exactly while the key is down; the stop key closes it too, and is the one key that also tells Luke to stop talking, while letting go of the talk key lets him finish. If Luke's key helper cannot start, the key reports presses alone, so one press opens the microphone and the next closes it, and the Keyboard shortcuts page says so.
  • Delete your account from the Account section in Settings. This erases your account, your sign-in records, your usage counts, any provider API keys you synced to the hosted service, your device rows, the conversation our service kept with its workspace files, and the stored roster of your sessions, and asks PostHog to erase your usage data and recordings. It does not reach a recording that was never attached to your account, as described above. Luke stops recording for the rest of the session, and starts again the next time you open it or sign in. Sentry reporting continues after deletion, and prior anonymous crash reports cannot be identified as yours and targeted through account deletion. Deleting does not affect your Google or GitHub account, and anything stored only on your Mac stays there until you remove it.

Google user data

Luke's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We use what Google returns when you sign in with it, your name and email address, only to identify your account. It is not transferred, sold, or used for advertising.

Contact

Email founders@stagereview.app with any questions about this policy.