What a Notch App Can See: NotchFit's Local-First Design, What the Claude Code and Codex Hooks Send, and What Stays on Your Mac

A notch app that shows what your coding agent is doing has, by definition, a view into your coding agent. Before you install one, the right questions are the boring ones: what does it see, where does that go, what runs on the network, and what would it take to audit the answer. This post answers those questions for NotchFit, using the product's own stated design rather than marketing adjectives, and it explains what "local-first" actually buys you in a menu-bar app that sits next to Claude Code and Codex all day.

The one-sentence version

NotchFit runs locally on your Mac and talks to itself over localhost. It has no account, sends no telemetry, and never uses the microphone. The only things that reach it are the events the Claude Code plugin and the Codex hooks hand over on your own machine, and those stay on your own machine.

What the hooks actually send

NotchFit gets its information from the agent the same way any Claude Code or Codex integration does: hooks. When you click Install / update integrations in NotchFit's Setup screen, it adds a Claude Code plugin and a set of Codex skills and hooks. Those hooks fire on the agent's lifecycle events, and they report to the NotchFit app over localhost. That is how the notch knows a task started, how it shows live progress on the right-hand side of the panel, how it shows Claude's summary when the task is done, and how it knows the agent is waiting on a permission prompt.

Two properties of that path matter for privacy and one matters for performance. The hooks are local: the destination is the NotchFit process on the same Mac, not a server. The hooks are yours: in Codex you trust them once via /hooks, and in both tools they live in the normal hook configuration you can read. And the hooks run asynchronously, so they never make Claude or Codex wait; the agent does not slow down because a workout panel is listening. If you want the general background on how this mechanism works, our Claude Code hooks guide covers the lifecycle events and what a hook can see.

What never leaves the Mac

• Your code. NotchFit is not an editor and not a reviewer. The agent's progress text it displays is shown in the notch and goes nowhere else.
• Your workout history. Streaks, the history heatmap and the record of which sets you finished are kept locally. There is no account to sync them to.
• Your plan details. The weekly plan asks about age, height, weight, fitness level, goal, equipment, days per week, minutes per day and injuries. When you generate it with /notchfit:plan in Claude Code or $notchfit-plan in Codex, those answers go to your AI agent, in your own session, under your own provider account, exactly like any other prompt you type there. NotchFit itself does not send them anywhere. If you would rather they not go to a model at all, the app's offline quick-plan generator builds a plan without any AI involvement.
• Your voice. NotchFit never uses the microphone. The optional spoken alerts, which announce when your agent is done or needs permission, use on-device macOS voices and can be muted from the notch.
• Usage data. There is no telemetry. NotchFit does not report which exercises you do, how often you code, or how long your agent runs take.

Why local-first is the right default for this category

Menu-bar utilities are the apps people audit least and trust most. They start at login, sit in the background for months, and are forgotten. That combination is exactly why a utility that watches an AI agent should have as little reach as possible. An agent's lifecycle events can include the names of files being edited, the text of a task, and a summary of what was done; any of that leaving the machine would turn a workout app into a data pipeline. Keeping the whole loop on localhost removes the question rather than answering it.

It also makes the product honest about failure modes. There is no service to go down, no subscription to lapse, and no account to be breached. If NotchFit is not running, the hooks have nobody to talk to and your agent carries on as if the app did not exist.

The things that do touch the network, and why

Local-first does not mean a hermit. Three things involve the outside world, and it is worth being precise about each.

• Buying and downloading. NotchFit costs $20 once and is sold on Whop; after purchase you download the signed and notarized DMG from your Whop account. That is a web checkout and a download, not something the app does once installed. There is no trial and no license key, so there is also no license server to phone home to.
• macOS code signing. Because the app is signed with a Developer ID and notarized, macOS may check its signature and notarization ticket when you first open it. That is Apple's process, applies to every notarized Mac app, and is part of why you should prefer notarized apps for anything that runs at login.
• Your AI agent. Claude Code and Codex talk to their providers as they always do. NotchFit does not sit in that path; it sees the local events those tools emit and nothing of the traffic between them and the model.

How to check the claims yourself

You should not have to take a blog post's word for a privacy property. Three checks take ten minutes.

1. Read the hooks. After Setup installs the integrations, open the Claude Code plugin's hook configuration and the Codex hooks and look at where they send events. You should see a localhost destination. The NotchFit user guide walks through where each integration is installed.
2. Watch the network. Run a trial workout with a firewall utility or a packet capture open, with your agent idle. A local-first app produces loopback traffic and nothing else. Then start an agent task and confirm the only new connections belong to Claude Code or Codex, not to NotchFit.
3. Check the microphone and permissions list. Under Privacy & Security in System Settings, NotchFit should not appear under Microphone at all, because it never requests it.

Where this sits next to other agent monitors

Many tools that notify you about agent activity are cloud services by necessity: if you want a message on your phone when Claude is done, some server has to relay it, and the right way to judge those tools is by how little they carry (an event name and a timestamp, not your diff). A phone-notification tool such as our own AI Done Now and NotchFit are complementary rather than competing: NotchFit is for the hours you are at the Mac, where it can show progress and a workout without any relay; a phone notification is for the hours you are not. The notch notifications post goes into how the at-desk alerts work, and why alerts wait until your set ends explains the one deliberate delay in the system.

The honest limits

Local-first solves the exfiltration question. It does not make the display private: whatever Claude's summary says will be visible in your notch, at the top of your screen, to anyone looking over your shoulder. If you work on sensitive code in a shared office, the Hide workout toggle does not hide the agent panel, and the panel collapses when nothing is running, so the exposure window is a running task, not the whole day. Plan accordingly, as you would with a terminal.

And local-first says nothing about what your agent itself sends to its provider. That is governed by Claude Code's and Codex's own settings and your account's data policies, not by anything NotchFit does. Keeping the workout app out of that conversation is the point; it is not a substitute for understanding the conversation.