Privacy and security

midcode is a desktop app that edits files on your Mac. There’s no midcode account, no server that sees your projects, and no analytics or telemetry in the app. Your code is read and written locally. What leaves the Mac is listed on this page: every destination, when it’s contacted, and what’s sent.

What stays on your Mac

• –

  Your code and every edit. midcode reads your files to find where to write, writes the change, and that’s all. Nothing is uploaded to be edited.

• –

  Your site. The canvas shows your own dev server, running on this Mac.

• –

  Comments, layer names, breakpoints and the rest of .midcode/: files in your project. See What midcode adds to your project.

• –

  The list of changes, recent projects, thumbnails and settings: in ~/Library/Application Support/midcode.

• –

  Layer naming and translation with Apple Intelligence. They use Apple’s on-device model through a small helper inside the app. midcode sends nothing anywhere for them, and they work offline.

midcode also turns off the telemetry of the dev servers it starts, where they have a switch: Next.js and Astro. From the next release it does the same for the Angular and Shopify CLIs, and for the tools New project runs.

What goes out, and when

In the next release:

Three more things connect, and none of them is midcode talking to a server of its own:

• –

  Your dev server does whatever your site does: its API calls, its fonts, its images.

• –

  Your agent talks to its provider with your account. See below.

• –

  Links midcode opens (the changelog, the checkout, a token page) go to your browser, never inside the app.

Where secrets are kept

Secrets are stored in ~/Library/Application Support/midcode, encrypted with a key from your macOS Keychain, and never inside a project.

Things to know:

• –

  If the Keychain isn’t available, midcode refuses to store GitHub and Vercel tokens. The other files are then saved unencrypted, readable only by your user.

• –

  “Use my GitHub CLI login” and “Use my Vercel CLI login” read the token those CLIs already have. Before a push, midcode also asks the GitHub CLI for the tokens of the accounts logged in to it, to find one that can push. Those stay in memory until you quit and are never written to disk.

• –

  For a Shopify store’s Admin API, midcode keeps no token at all. The Shopify CLI holds the session.

• –

  A connection string that’s in your .env stays there. midcode reads it each time and saves no copy.

What the window never gets

midcode has two parts: the main process, which reads files, runs commands and holds secrets, and the window you see. The window is treated as the less trusted one, because your site runs inside it.

• –

  Tokens, API keys and passwords never reach the window. It’s told that GitHub is connected and as which account, never the token.

• –

  Database connection strings never reach it either. It knows where a database is (host, port, name), never how to get in. They aren’t put in reports or handed to the agent.

• –

  Values of environment variables. The Environment variables view knows whether a variable is set, not what it holds. A value you type is written to the file and forgotten.

• –

  Paths. The window asks for changes by project, and the main process checks that every file it writes is inside that project’s folder.

• –

  Your site can’t talk to the main process. Every request is checked to come from midcode’s own page; one from a frame of the canvas is refused.

A value you type into a field (a token, a connection string, a password) passes through the window once, on its way in.

Your agent

The Agent tab runs an agent you already have (Claude Code, Codex, Gemini CLI, OpenCode, Cursor) as a program on your Mac, in your project’s folder, signed in with your account. midcode shows the conversation, but it isn’t in the middle of the agent’s traffic, and none of it goes to midcode. What the agent sends to its provider is between you and that provider.

• –

  midcode gives the agent what you send it: your message, attachments, and the references you picked (an element, a comment, a CMS item).

• –

  A database table or row goes to the agent only if you pick it. A connection string never does.

• –

  In the chat, midcode answers the agent’s requests to read and write files only for files inside the project, and shows its permission requests for you to answer.

• –

  The agent is still a program running as you, with its own tools. Its own permission settings decide what else it can do.

The canvas and your site

• –

  The window frames one thing: your dev server. In the released version that means addresses on this Mac. From the next release a site can live on another host (app.test), and a frame is allowed only when it’s the site of a project you opened.

• –

  A site may forbid being framed (X-Frame-Options, frame-ancestors). midcode removes that for your dev server’s address only.

• –

  A dev server’s self-made https certificate is accepted for localhost, 127.0.0.1 and *.localhost only. Every other host is checked like any site.

• –

  A link in your site that tries to take over the window opens in your browser instead.

• –

  midcode’s own interface runs no script from the network. Its Content Security Policy allows scripts and styles from the app only.

Edits and the trial

• –

  The main process refuses every write without a license or a running trial. The paywall isn’t the only lock.

• –

  The trial’s start date is kept in three places, so deleting midcode’s folder doesn’t restart it: license.bin, the file ~/Library/Preferences/app.midcode.trial, and a Keychain item named app.midcode. The last two hold a date and nothing else.

• –

  midcode remembers the latest time it has seen, so setting the clock back doesn’t extend a trial.

The app

• –

  Signed and notarized. Releases are built, signed and notarized in CI and published to the public repository agusdellaquila/midcode. The source is not public.

• –

  Updates are verified. The updater checks the signature of what it downloaded before installing it.

• –

  It only runs its own code. The app loads only the bundle it was signed with; a changed one doesn’t start.

• –

  No debugger. The released app has no developer tools and quits if started with a remote debugging or inspector flag.

• –

  A sandboxed window. The window runs sandboxed and isolated from Node, and reaches the main process only through a fixed list of calls.

What a report contains

“Send report”, “Copy report” and the Feedback form send the same text, and the form shows it before it goes. It has your Mac’s model, how the project is set up, the project’s dev config files whole (vite.config, next.config, svelte.config, astro.config, nuxt.config, react-router.config or remix.config at its root, up to 6,000 characters each) and the dev server’s whole log. It never has any other source file, .env values or secrets. The full list is in Troubleshooting.

Limits

• –

  midcode starts tools that aren’t its own: your package manager, your framework’s dev server, git, npx, the Shopify CLI, your agent. Each of them has its own network behavior and its own privacy policy.

• –

  The dev server log and the dev config files are part of a report. If your server prints a secret, or a config file has one written in it, the report has it: read it before sending.

• –

  Avatars of your GitHub and Vercel accounts are loaded from those services when Settings is open.

• –

  Anyone with access to your Mac user account can read midcode’s folder. The encrypted files need your Keychain to open.