DEV Community: E Daugherty LLC

Which Coding Agent Is Waiting on You? Wiring Claude Code and Codex Into One Status Board on a Mac

E Daugherty LLC — Fri, 13 Nov 2026 19:23:22 +0000

Running two or three coding agents at once sounds efficient until you count the dead time. One terminal finished four minutes ago and is sitting at a prompt. Another stopped to ask whether it may run npm install, and you never saw the question because that tab was behind your editor. The third is still working, so you keep checking it, which is the only one that did not need you.

The expensive part is not the model. It is the gap between "the agent needs a human" and "the human notices." This post shows how to close that gap with the hooks both tools already ship, using nothing but a shell script, jq, and a folder of small JSON files. You can copy it as is. At the end I show the view I use for the same job, but nothing here depends on it.

The three states that matter

Every session you care about is in one of three states:

Working. Leave it alone.
Needs you. It is blocked on a permission prompt or a question. Every minute here is wasted.
Done, your turn. It finished the turn and wants review or the next instruction.

A useful board only has to answer one question: which sessions are in state 2 or 3, and in which folder?

What Claude Code gives you

Claude Code runs hooks at fixed points in a session. A hook is a command that receives JSON on stdin. Every event includes session_id, cwd and hook_event_name, which is exactly what a board needs to tell sessions apart.

Three events map onto the three states:

UserPromptSubmit fires when a prompt is submitted. That means working.
Notification fires when Claude Code sends a notification. Its matcher is the notification type, and the documented types include permission_prompt and idle_prompt. That means needs you.
Stop fires when Claude finishes responding. That means done, your turn.

Put this in ~/.claude/settings.json so it applies to every project on the machine (a project's .claude/settings.json works too, but then it only covers that repo):

{
  "hooks": {
    "UserPromptSubmit": [
      { "hooks": [{ "type": "command", "command": "~/.agent-status/report.sh working" }] }
    ],
    "Notification": [
      { "matcher": "permission_prompt|idle_prompt",
        "hooks": [{ "type": "command", "command": "~/.agent-status/report.sh needs_you" }] }
    ],
    "Stop": [
      { "hooks": [{ "type": "command", "command": "~/.agent-status/report.sh done" }] }
    ]
  }
}

The reporter script

One file per session, overwritten on every event. No database, no daemon.

#!/bin/bash
# ~/.agent-status/report.sh <state>
state="$1"
input=$(cat)
dir="$HOME/.agent-status/sessions"
mkdir -p "$dir"

id=$(jq -r '.session_id // empty' <<<"$input")
[ -z "$id" ] && exit 0

jq -nc \
  --arg state "$state" \
  --arg agent "claude" \
  --arg cwd "$(jq -r '.cwd // ""' <<<"$input")" \
  --arg msg "$(jq -r '.message // ""' <<<"$input")" \
  --arg at "$(date +%s)" \
  '{state:$state, agent:$agent, cwd:$cwd, msg:$msg, at:($at|tonumber)}' \
  > "$dir/$id.json.tmp" && mv "$dir/$id.json.tmp" "$dir/$id.json"

if [ "$state" = "needs_you" ]; then
  osascript -e "display notification \"$(basename "$(jq -r '.cwd // ""' <<<"$input")") needs you\" with title \"Claude Code\""
fi
exit 0

Three details that save debugging time:

Write to a temp file, then mv. A reader that lists the folder mid write will otherwise hit half a JSON object. mv within one volume is atomic.
Exit 0 and stay fast. Hooks run inline with the session. A slow hook is a slow agent.
Don't write to /dev/tty. The docs are explicit that hooks run without a controlling terminal. If you want a terminal-native alert instead of osascript, return a terminalSequence field from the hook and Claude Code writes the escape sequence for you, in an interactive session.

chmod +x ~/.agent-status/report.sh and start a session. You should see a file appear in ~/.agent-status/sessions/ on your first prompt.

What Codex gives you, and what it doesn't

Codex has a notify setting that runs an external program with a JSON argument. The documented catch: it currently fires for one event, agent-turn-complete. The payload includes type, thread-id, turn-id, cwd, input-messages and last-assistant-message.

So Codex can tell your board done, keyed by thread-id, but notify cannot tell it needs you. Add it to your user-level ~/.codex/config.toml (Codex ignores notify in a project-local config and warns about it):

notify = ["/bin/bash", "-c", "~/.agent-status/codex.sh \"$1\"", "codex-notify"]

#!/bin/bash
# ~/.agent-status/codex.sh '<json>'
payload="$1"
[ "$(jq -r '.type' <<<"$payload")" = "agent-turn-complete" ] || exit 0
id=$(jq -r '."thread-id"' <<<"$payload")
dir="$HOME/.agent-status/sessions"; mkdir -p "$dir"
jq -nc --arg cwd "$(jq -r '.cwd // ""' <<<"$payload")" --arg at "$(date +%s)" \
  '{state:"done", agent:"codex", cwd:$cwd, msg:"", at:($at|tonumber)}' \
  > "$dir/codex-$id.json.tmp" && mv "$dir/codex-$id.json.tmp" "$dir/codex-$id.json"

For approvals, lean on the TUI instead. Codex's built-in tui.notifications can filter by event type, including approval-requested, and tui.notification_condition controls whether it fires only when the terminal is unfocused. That gives you an alert, not a board entry, which is an honest limit worth knowing before you build around it.

Reading the board

#!/bin/bash
# ~/.agent-status/board
now=$(date +%s)
for f in ~/.agent-status/sessions/*.json; do
  [ -e "$f" ] || continue
  jq -r --argjson now "$now" \
    '[.state, .agent, (.cwd|split("/")|last), (($now-.at)/60|floor|tostring)+"m ago"] | @tsv' "$f"
done | sort | column -t

Sorting puts done and needs_you above working alphabetically, which happens to be the order you want. Run it with watch -n 5 ~/.agent-status/board in a spare pane, or bind it to a key.

Two cleanup rules keep it honest:

Expire stale files. A session you closed with Ctrl+C never fires Stop. Drop anything older than a few hours: find ~/.agent-status/sessions -mmin +240 -delete.
Treat "working" as a claim, not a fact. It only means the last event was a prompt. If a process crashed, the file still says working. Age is your sanity check.

Where this breaks

Cloud sessions. Claude Code's docs note that cloud sessions don't read your local ~/.claude/settings.json, so those sessions never reach your board.
Subagents. Tool hooks also fire inside subagents, with agent_id set. If you later add PreToolUse reporting, key on it or one subagent will overwrite the parent's state.
Codex approvals. Covered above: notify will not see them.

The version I look at

I build TokenBar, a macOS 14+ menu bar app that shows usage and reset times for Claude, Codex, Cursor, Gemini and Copilot. It is built on Peter Steinberger's MIT-licensed CodexBar. It also has a panel for Pixel Agents, a separate MIT open-source project that draws coding sessions as people at desks. The panel connects to your own local Pixel Agents build (Node.js 20 or newer) rather than bundling it.

The screenshot is demo mode with fictional projects. It sorts the same three states this post builds by hand: who is working, who is done and waiting for your turn, and who needs your OK. If the script above is enough for you, keep the script. TokenBar is $5/month Basic or $15 lifetime Pro and does not add any quota to your plans.

Disclosure: I build TokenBar.

Metering a Free Tier by Words Instead of Days in a Mac App

E Daugherty LLC — Fri, 13 Nov 2026 17:21:13 +0000

On November 11, DraftKey shipped two releases about six hours apart. Version 0.1.61 made the app free to try with 2,000 words of writing help per Mac. Version 0.1.62 cut that to 500 words, added a warning when about 100 words are left, and changed what the app looks like once the allowance runs out. Both release notes are public, and they are the source for every DraftKey detail in this post.

We build DraftKey, a Mac app for Tab autocomplete and rewrites you review before they are inserted. This is not a pricing post. It is about the engineering decisions hiding behind a sentence like "every Mac gets 500 free words," because almost none of them are obvious until you have to ship one.

Why words, not days

The default trial for desktop software is a clock: 7 or 14 days, then a paywall. A clock is easy to build and easy to explain. It is also a poor match for a tool you use in short bursts. Someone installs a writing helper on a Monday, uses it twice, gets busy, and comes back on day 15 to a locked app they never really tried.

A usage allowance is consumed only when the feature does work. Nobody loses their trial to a vacation. The tradeoff is that you now have to define the unit precisely, count it reliably, and show the count somewhere people will see it. A day counts itself. A word does not.

Decide what is metered, and fence off what is not

The first design question is scope. DraftKey's notes list what the allowance covers: suggestions, Writing tools, and slash commands. They are just as explicit about what it does not cover: keyboard sounds and clipboard history "stay free and are never counted."

That second list matters more than it looks. If a feature is promised as free, it should be impossible for it to touch the meter, not merely unlikely. In practice that means the counting call lives in one place, on the path where model output is actually delivered, rather than being sprinkled through the app. Features that never reach that path cannot decrement the allowance by accident.

You also have to pick a counting rule and stick to it. Words typed by the user, words suggested, or words actually accepted are three different numbers. Whatever you pick, make it the one a user would guess if you asked them, because the count is going to be displayed and they will compare it with their own sense of how much they used.

Device identity on macOS, without shipping a hardware ID

"The free word count belongs to your Mac" sounds simple. It requires a stable answer to "which Mac is this?" that survives an app reinstall, because a counter that resets when someone drags the app to the Trash and back is not much of a limit.

macOS gives you a few options, each with costs:

A random UUID you generate and store. UserDefaults is wiped by deleting the app's preferences. The Keychain survives reinstalls but can be removed by the user. Either is fine for convenience and weak as an allowance anchor.
A hardware-derived identifier. IOKit exposes a platform UUID on the IOPlatformExpertDevice registry entry (the IOPlatformUUID property), which stays the same across reinstalls of your app. It is also a persistent identifier for that machine, which is exactly why it should never leave the Mac in raw form.
An account. Requiring sign-in solves identity cleanly and adds friction to the first minute, which is the minute a free tier exists to protect.

Whatever source you use, send a derived value instead of the raw one. A keyed hash, such as an HMAC from Apple's CryptoKit with a key specific to your app, gives your server a stable identifier for the Mac without handing it a hardware ID that could be matched against other services. DraftKey's notes describe this part in plain terms: it checks the count online "with a hashed identifier for your Mac and a number of words, never your writing." That is the whole payload a meter like this needs.

Send counts, not content

A writing app has an obvious temptation here: the text is right there, so why not send it and count server-side? Because it turns a billing feature into a data-collection feature. The server only needs two facts to enforce an allowance: who is asking (the hashed device value) and how many units were used. Keep the request that small and the privacy story of the meter is easy to state and easy to verify by watching the traffic.

Batching helps too. Reporting after every accepted suggestion makes the meter chatty and fragile on bad networks. Reporting accumulated counts periodically, with the server holding the authoritative total, keeps the request rate low. You will still have to decide what happens offline: whether to allow a small local grace amount or pause until the count can be confirmed. Neither choice is wrong, but it should be a decision, not whatever the networking code happens to do on timeout.

Warn before zero

For most metered products, running out is an annoyance. For an autocomplete tool it can look like a malfunction. Suggestions simply stop appearing, in the middle of a sentence, and the most reasonable conclusion a user can draw is that the app broke.

0.1.62 addresses that from two directions. DraftKey gives a heads-up when about 100 free words are left, "so writing help never stops mid-sentence without warning." And once the words are gone, Autocomplete and Writing tools "say they are paused, with a lock, once the free words are gone, instead of looking broken."

That second change is worth copying even if you never meter anything. Every state a feature can be in should be visibly distinct: on, off by choice, unavailable because of a permission, unavailable because of the plan. If two of those look the same, your support inbox becomes the place where users find out which one they hit.

Put the meter where the decision happens

The same release gave the free plan its own card on Home: how many words are left, what stays free forever, what a license adds, and a single button to buy it. License activation moved to that card as well. Home and the menu bar both show the remaining count.

The engineering point is co-location. The number, the explanation of what it limits, and the way to remove the limit belong in one place. Splitting them across Settings, an About pane, and an email after purchase means users have to reassemble the model in their heads, and many will not.

Assume the number will change

The allowance went from 2,000 to 500 words between two releases on the same day. Whatever your first number is, plan for it to move. That suggests a few concrete things:

Keep the allowance value out of scattered UI strings, so a change does not mean hunting for every place "2,000" was typed.
Decide up front how a change applies to people who already started: whether the server stores words used or words remaining determines whether a reduction can push someone straight to zero.
Write the release note in plain numbers. "The free allowance is 500 words of writing help per Mac, down from 2,000" is the kind of sentence that prevents a confused support thread.

What I would carry into any usage-metered desktop app

Meter only the expensive path, and make free features structurally unable to touch the counter.
Pick a unit users would count the same way you do.
Anchor the allowance to the device with a derived, keyed value, never a raw hardware identifier.
Send a count and an identifier, nothing else.
Warn before the limit, and make "paused by plan" look different from "broken."
Keep the count, the explanation, and the upgrade path together.

Where DraftKey fits

Disclosure: I build DraftKey. It needs an Apple Silicon Mac on macOS 14 or later, and its writing features need at least 8 GB of memory and a separate writing-model download of about 1.12 GB, with at least 2.2 GB of free space. Each Mac gets 500 free words of writing help, and a license is $4.99 once for up to three Macs. It works in compatible text fields, not every app. You can see how it works here.

If you have shipped a usage-based trial in a desktop app, what unit did you meter, and how did you handle the moment someone went offline mid-allowance?

Sources

DraftKey 0.1.61 and 0.1.62 release notes: https://github.com/auratechnologiesllc/DraftKey/releases
Apple, CryptoKit HMAC: https://developer.apple.com/documentation/cryptokit/hmac
Apple, IOKit: https://developer.apple.com/documentation/iokit

Don't Collect Another API Key: Reusing the AI Logins Already on a Mac

E Daugherty LLC — Fri, 13 Nov 2026 16:10:38 +0000

The remaining allowance on a coding agent is not a secret. It already lives behind a login you completed in that vendor's own app or CLI. Claude Code has /usage. Codex has /status. Cursor, Gemini, and GitHub Copilot each have a usage page of their own. If a menu bar meter asked you to paste a fresh API key for every one of those tools, it would be asking you to open a second billing path and to store a second secret, just to read a number you can already see.

We build TokenBar, a macOS 14+ menu bar app at Aura Technologies that shows usage and reset times for Claude, Codex, Cursor, Gemini, and Copilot. It is built on CodexBar, Peter Steinberger's MIT-licensed project, and it can connect to a local install of Pixel Agents, a separate MIT-licensed project. TokenBar does not add any quota. This post is about a design choice we kept in front of us while wiring those providers up: reuse the login that is already on the Mac, instead of collecting a new API key as the normal path.

An API key is often the wrong kind of credential

For many of these tools, the subscription you already pay for and an API key are not the same thing.

Claude Code usage on a Pro, Max, or Ultra plan is the plan allowance, shared with Claude on the web and on the desktop, and you read it with /usage or in Settings, under Usage. Anthropic documents that in its help center and in the costs guide. An Anthropic Console API key is a different billing path.

OpenAI's Codex pricing page tells you to check remaining limits in the Codex usage dashboard, or with /status during a CLI session. Local sessions and cloud chats share the plan allowance. A usage-based API key is listed as a separate column. If a tracker required that key, it would be tempting to assume it was reading the same pool you care about. It might not be.

Cursor is explicit about the same split. Its usage documentation says that on individual plans, requests made with your own API key do not count toward included usage. Your provider bills you directly. A meter that only knew how to call an API with a key you pasted would miss the weekly or monthly pool you were trying to watch.

So "just paste your API key" is not a shortcut. It is often a request for the wrong credential, plus a new secret sitting in someone else's app. The better starting point is: you already signed in to the vendor. Use that.

What reuse looks like in the menu bar

When TokenBar is connected, the menu can name the source it is using. On a Mac where Codex is signed in, that line has read "Live process detected (Codex app) - Source: OAuth," next to the session and weekly bars and the time until reset. The useful part of that sentence is the source. The app is not asking you to type a key into a form. It is using a login that Codex already has.

The same idea applies to the other advertised providers, with a per-provider source you can choose when more than one is available:

Claude can follow a Claude Code login, or a signed-in claude.ai session, or the claude CLI.
Codex can follow the Codex CLI or app login, or a signed-in ChatGPT session.
Cursor can follow the Cursor app or a signed-in browser session.
Gemini can follow a Gemini CLI login.
Copilot can follow a GitHub login. GitHub's own apps often use device authorization for that kind of sign-in, so you approve it on GitHub rather than pasting a token by hand.

The point is not that every provider speaks one protocol. They do not. CodexBar's own provider list, which is much longer than TokenBar's advertised set, is a reminder of how many ways a usage number can be fetched: official APIs, OAuth, device flow, a browser session, CLI output, local files. The point is that the default should be "use the session you already created," and that the menu should say which source is in play.

We do not treat unadvertised providers as part of this product story. The advertised set is Claude, Codex, Cursor, Gemini, and Copilot. If you need a longer list, CodexBar is the open-source baseline, it is free, and it is very good.

The tradeoffs you actually hit

Reusing a login is cleaner on paper than it is in a menu bar that should stay quiet.

Expiry belongs to the vendor. If an OAuth token has expired, the honest fix is to let the vendor's own app or CLI refresh it, then read again. Inventing a parallel login just so a meter can keep working is how you end up with a second, half-documented session and a confusing sign-out story. When something is stale, the message should tell you to sign in to the tool you already use, not to invent a TokenBar account for that provider. TokenBar does not need a separate Claude, Codex, or Cursor account of its own.

Keychain prompts can become noise. Credentials on a Mac often live in the Keychain. A status item that wakes, reads a token, and puts a Keychain dialog in your face every few minutes is worse than no meter. TokenBar has a setting to avoid those prompts, and it backs off for a while after a prompt is denied, so one "Deny" does not turn into a loop. That is a real tradeoff: less nagging, and a stretch of time where a denied or locked Keychain means the meter cannot refresh. Asking someone to unlock the login Keychain is the right error when that is actually the problem. It is the wrong thing to ask every time the menu opens.

A browser session is a fallback, not a tutorial in moving cookies around. Some providers can be read from a session you already have in a browser. That can unblock someone who uses the web app more than the CLI. It is also easy to document badly. We would rather tell you to choose a source in the app than publish a recipe for copying cookie headers.

Reading usage does not change usage. This should go without saying, and it still needs saying. A meter is a view. Official plan limits, reset times, and what happens when you hit them still come from the vendor. TokenBar gives you no extra quota, and it does not replace Settings, /usage, or /status.

The app is not a claim that nothing ever leaves the Mac. License checks, checkout, and similar account traffic go to TokenBar's own service. Reusing a vendor login is a decision about how we read that vendor, not a promise that the utility has no network of its own.

What I would tell anyone building a sidecar for a tool people already pay for

Prefer the login the user already completed. If the number you want is on a subscription plan, an API key is often a different number.
Show the source. "OAuth," "CLI," or "web session" in the UI saves a lot of guesswork when the number looks wrong.
Let the vendor refresh its own tokens. Your job is to notice that the session is stale and send the user back to the official sign-in.
Treat Keychain as a scarce attention budget. Prompt when you must, back off when the user says no, and do not poll in a way that makes the system ask again.
Say what you do not do. No extra quota. No second provider account if you can help it. No implication that watching the meter is a privacy guarantee.

Where TokenBar fits

TokenBar runs on macOS 14 or later. Basic is $5 a month. Pro is $15 once, a lifetime license. You choose the plan in the app. It shows usage and reset times for the advertised providers, and it does not increase any of their allowances. If you want the open-source menu bar meter on its own, start with CodexBar. If you want to look at TokenBar, it is at tokenbar.site.

When you connect a third-party utility to a provider you already pay for, do you want it to reuse the existing login, even if that means a Keychain prompt, or would you rather paste a dedicated key so the access is obvious and easy to revoke?

Sources

Anthropic, Use Claude Code with your Pro, Max, or Ultra plan: https://support.claude.com/en/articles/11145838-use-claude-code-with-your-pro-max-or-ultra-plan
Anthropic, Manage costs effectively: https://code.claude.com/docs/en/costs
OpenAI, Codex Pricing: https://chatgpt.com/codex/pricing/
Cursor, Usage and limits: https://cursor.com/help/models-and-usage/usage-limits
GitHub, Authorizing OAuth apps (device flow): https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#device-flow
CodexBar (MIT), Peter Steinberger: https://github.com/steipete/CodexBar
Pixel Agents (MIT): https://github.com/pixel-agents-hq/pixel-agents

Why a Mac Writing Helper Needs Two Permissions, and Why It Still Refuses Password Fields

E Daugherty LLC — Fri, 13 Nov 2026 16:10:01 +0000

A writing helper that works inside someone else's text field has to ask macOS for a lot of trust. Accessibility permission is how an app reads and, if you approve it, replaces text in another app. Input Monitoring is how it can see keyboard events while you are in Mail, Notes, or a browser. Those are two different Privacy & Security toggles, and they should be. People are right to pause on both.

We build DraftKey, a Mac app for Tab autocomplete and rewrites you review before they are inserted. This post is about the permission model behind a helper like that: why two system permissions are required, how we ask for them, and the cases we refuse even after you have said yes. The general mechanics come from Apple's public documentation, linked at the end. The product rules come from the shipped app's own wording, including the Apps & privacy section in Settings.

Two panes, two jobs

Apple documents these as separate resources, and System Settings treats them that way.

Accessibility is under Privacy & Security. It is the permission that lets an app control your Mac on your behalf: read user interface elements, including text, and change them. A Mac app can ask whether it is a trusted Accessibility client with AXIsProcessTrustedWithOptions. If the process is not trusted, it cannot usefully work in another app's field. The honest usage description is therefore about suggestions and about replacing text only when the user approves, not about "making writing nicer" in the abstract.

Input Monitoring is a different list. Apple's own support page is blunt about what it means: some apps can monitor your keyboard, mouse, or trackpad even when you are using other apps. You turn that ability on or off per app. Apple's documentation for resetting TCC access even uses a different service name for it, ListenEvent, alongside a separate PostEvent service for sending keystrokes and a separate Accessibility service. If you have ever wondered why a shortcut utility and a window manager can end up in different panes, that split is why.

DraftKey needs both, for different reasons. Reading a compatible text field, and writing a rewrite back after you press Insert, is an Accessibility job. Noticing Tab when a suggestion is showing, or Command-Option when you want Writing tools, is a keyboard job. Typing sounds, which are a separate feature you can turn off, also need keyboard access. The in-app prompts say so directly: "Allow Input Monitoring for shortcuts and typing sounds," and "Allow Accessibility and keyboard access in DraftKey."

Lumping those into one explanation is how permission dialogs start to sound like a blank check. Keeping them separate is more work in onboarding, and it is clearer.

Ask, then get out of the way

The system already has a prompt and a Settings pane for each permission. The useful work in the app is not inventing a third one. It is sending people to the right pane, then noticing when they come back.

DraftKey's onboarding copy is: "Approve DraftKey in the macOS prompt or System Settings, then return here." Settings also has a Refresh permissions action. That sounds minor until you remember how often a Mac permission is granted to one build, then seems to vanish after a move, a rename, or a reinstall. Apple publishes a tccutil-based reset procedure for developers for exactly this class of problem. Users should not have to learn that command. They should have a button that re-checks trust and, if needed, opens the same Privacy & Security pane again.

A good permission ask is specific about what you will and will not do. "Allow access to your keyboard and supported text fields" is narrower than "allow this app to control your Mac," and it is closer to the truth. It also leaves room for the next section, which matters more than the wording of the dialog.

Permission granted is not permission everywhere

Once both system toggles are on, the dangerous default is "every text field, every app." We do not take that default.

Settings includes an Apps & privacy section whose subtitle is "Choose where DraftKey works." You can turn writing help off for an individual app. If you invoke it in a place that is turned off, the app tells you: "Writing help is turned off for this app. Review Apps & permissions in DraftKey." That is an allowlist you can edit, not a one-time consent that silently covers the whole machine.

Some exclusions are not optional, and they are not buried.

Password fields are always excluded.
Password managers always exclude writing help and typing sounds.
Terminals start with sounds only. Writing help is off there until you change it.
When secure input is active, writing help is unavailable. The message is: "Writing help is unavailable while secure input is active. Click a normal text field and try again."

The last two points are worth unpacking, because they are easy to misread as bugs.

Apple's NSSecureTextField is the standard password field. It displays bullets instead of characters and does not allow cutting or copying its contents. A writing helper that suggested the next word in a password field, or offered to "rewrite" it, would be doing the wrong thing even if the user had granted Accessibility. So the rule is not "skip password managers we recognize." It is "skip password fields, wherever they appear."

Secure input is broader than a single field. When a Mac app enables secure keyboard entry, the system is telling other processes to stop observing those keystrokes. Apple documented the fair use of this mechanism years ago in Technical Note TN2150, Using Secure Event Input Fairly: turn it on only while sensitive input is happening, and turn it off afterward, because leaving it on breaks other software. From the helper's point of view, the only correct behavior while secure input is on is to refuse. If a password prompt is in front, or a terminal has Secure Keyboard Entry enabled, DraftKey should not try to be helpful. It should wait until you click a normal text field.

Terminals are a softer default, not a hard ban. A terminal looks like a text field, and some of what people type there is just a commit message. A lot of it is not: commands, tokens, remote sessions. Starting with sounds only, and leaving writing help off, means the app is present without reading shell input until you opt in for that specific app. You can still enable it if your actual use is writing prose in that window. The default assumes you might not be.

Compatible fields, not every app

Even in apps you have allowed, support depends on how the editor exposes its text. Some custom editors do not. DraftKey is a helper for compatible text fields, not a claim that every Mac app will work. That limit belongs next to the permission talk, because a user who has just opened Accessibility and Input Monitoring deserves an accurate picture of what those permissions buy.

The same honesty applies to what the app does after you grant them. Tab autocomplete suggests the rest of a sentence and adds it only when you accept it. A rewrite opens a preview, and nothing is written back until you choose Insert. Those are separate actions, and both are opt-in at the moment of use. Granting a system permission is not the same thing as accepting a change.

What I would tell anyone asking for these permissions

Treat Accessibility and Input Monitoring as different asks. They live in different panes because they do different things. Explain each one in a sentence, not as a bundle.
Send people to System Settings, then detect the return. A custom primer screen cannot grant the permission for them. A refresh action can close the loop.
Do not let system consent become app-wide access. Give people an apps list. Default sensitive classes off, or exclude them entirely.
Refuse password fields and secure input, even if the APIs would let you try. If your feature is writing help, those contexts are not writing.
Say "compatible text fields" and mean it. A permission grant does not make an inaccessible editor accessible.

Where DraftKey fits

If you want to try the result, DraftKey needs an Apple Silicon Mac on macOS 14 or later, and its writing features need at least 8 GB of memory and a separate writing-model download of about 1.12 GB, with at least 2.2 GB of free space. Every Mac gets 500 free words of writing help. After that it is $4.99 once, for up to three Macs you own. It works in compatible text fields, password fields are excluded, and some custom editors are not supported. You can read more about it here.

If you ship a Mac app that needs Accessibility or Input Monitoring, how do you explain the ask without making it sound like a blank check? And which apps did you default to off?

Sources

Apple Support, Allow accessibility apps to access your Mac: https://support.apple.com/guide/mac-help/allow-accessibility-apps-to-access-your-mac-mh43185/mac
Apple Support, Control access to input monitoring on Mac: https://support.apple.com/guide/mac-help/control-access-to-input-monitoring-on-mac-mchl4cedafb6/mac
Apple, Resetting access to protected resources in macOS: https://developer.apple.com/documentation/xcode/resetting-access-to-protected-resources-in-macos
Apple, NSSecureTextField: https://developer.apple.com/documentation/appkit/nssecuretextfield
Apple, Technical Note TN2150, Using Secure Event Input Fairly: https://developer.apple.com/library/archive/technotes/tn2150/_index.html
DraftKey public release notes: https://github.com/auratechnologiesllc/DraftKey/releases

Shipping 52 Releases of a Mac App: What Signed Updates Have to Get Right

E Daugherty LLC — Fri, 13 Nov 2026 14:52:36 +0000

Your first auto-update is a promise. Your second one is where you find out whether you kept it.

We build DraftKey, a small Mac app for Tab autocomplete and reviewed rewrites. Between September 20 and November 11, 2026 we tagged 52 public releases on GitHub, from 0.1.1 to 0.1.62. That is a lot of updates to push at people who installed a writing tool and mostly want it to stay out of the way. This post is about the boring plumbing that made that pace survivable, and the one early bug that forced users to reinstall by hand.

Everything about DraftKey below comes from our public release notes. The general mechanics come from Apple's and the Sparkle project's public documentation, linked at the end. If you ship a Mac app outside the App Store, most of this applies to you whatever updater you use.

Release 0.1.1: decide what an update must never touch

The 0.1.1 notes are short, and every line is a rule we still follow:

You can check for and install signed updates from the menu bar or from Settings, under About.
Automatic update checks can be turned off.
Installing an update requires your approval.
Updates preserve your license, your preferences, and the downloaded writing model.

The last line matters more than it looks. DraftKey's download is about 1.12 GB and needs about 2.2 GB of free space, because it ships with a writing model. If an update quietly dropped that model, or reset the license, every release would feel like a reinstall. So before shipping a second version, write down the state that has to survive an update. For us it was three things: the license, the preferences, and the model. Then keep that state outside the app bundle, because the bundle is exactly what gets replaced.

Release 0.1.2: the updater bug you can't update your way out of

The very next release, the same day, says this:

Fix Check for Updates and automatic update checks failing to start. Verify signed updates before extracting them, as required for signed feeds.

And then the uncomfortable part:

If you installed 0.1.0 or 0.1.1, download this installer once and replace DraftKey in Applications.

That is the trap. When the updater itself is broken, the fix can't reach anyone through the updater. Everyone on the broken build has to come back to your website and reinstall manually, and most of them won't know they need to.

Two lessons came out of that.

Test the update path, not just the app. Before a release goes out, install the previous public build on a clean machine or user account and update it to the new one through the real feed. Launching the new build on its own tells you nothing about whether people can get to it.

Verify before you unpack. Sparkle's documentation describes the model most Mac updaters follow. You generate a key pair once with its generate_keys tool, which keeps the private key in your Keychain. You ship the public key inside the app, sign each update archive with sign_update, and the app refuses any archive whose signature doesn't match. The order matters. Check the signature first and only then extract, so a tampered or corrupted archive never gets unpacked into a temporary folder at all.

Signing and notarization are two different checks

People mix these up, so here is the short version from Apple's documentation.

Code signing with a Developer ID says who built the app and that it hasn't changed since it was signed.
Notarization means you upload the signed build to Apple's notary service, which runs automated checks and returns a ticket. Apple requires the hardened runtime for notarized apps. You submit with xcrun notarytool submit and attach the ticket to the disk image or app with xcrun stapler staple, so Gatekeeper can verify it even when the Mac is offline at first launch.
Update signing, like Sparkle's EdDSA signature, is separate again. It protects the update feed, not first launch.

You want all three. Our 0.1.56 and 0.1.57 notes both lead with the same sentence, "Freshly built, signed, and notarized installer," and both open the standard drag-to-Applications window. A boring, familiar first install is a feature.

Ask before installing, and let people turn it off

It is tempting to update silently. We went the other way on purpose. Checks can be disabled, and an install waits for your approval. For a tool that sits in your text fields all day, the update should never be the thing that interrupts a sentence.

Making updates visible also helped in ways we didn't plan for. Release 0.1.11 added an update check right inside onboarding, along with a persistent update status. Someone who downloads an older installer from a cached link gets told right away that a newer build exists, before they form an opinion from stale code.

Write release notes for the person, not the commit log

Look at almost any of the 52 notes and you will see the same shape: what changed for you, in plain words, and occasionally what you have to do. Release 0.1.33 says checks "resume after memory pressure clears." Release 0.1.60 says the Open DraftKey button on the website "now starts guided setup, the same as opening it from Applications." There is no "refactored the state machine" in there.

When the notes are readable, they can do two more jobs. They tell users when an update is worth installing, and later they give you an honest public record. This post leans on that record instead of memory.

A checklist if you ship Mac updates yourself

List the state an update must preserve, and keep it outside the app bundle.
Ship your update signing public key in the very first public build. Adding it later means one more manual reinstall for everyone.
Verify the signature before extracting anything.
Before every release, update the previous public build through the real feed.
Sign with Developer ID, enable the hardened runtime, notarize, and staple the installer.
Ask before installing, and let people turn automatic checks off.
Treat an updater bug as a special incident: put the manual reinstall instructions in the release notes and on the download page.

If you want to see how this feels from the user side, DraftKey is at getdraftkey.com. It needs an Apple Silicon Mac on macOS 14 or later with 8 GB of RAM.

What broke the first time you shipped an updater? I'm especially curious whether anyone found a clean way to rescue users stuck on a build with a broken update check.

Sources

DraftKey public release notes: https://github.com/auratechnologiesllc/DraftKey/releases
Sparkle documentation: https://sparkle-project.org/documentation/
Apple, Notarizing macOS software before distribution: https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution
Apple, Hardened Runtime: https://developer.apple.com/documentation/security/hardened-runtime

How a Menu Bar App Reconstructs Codex and Claude Code Usage Limits

E Daugherty LLC — Fri, 13 Nov 2026 02:02:20 +0000

If you have typed /status in Codex, or /usage in Claude Code, and then opened Settings → Usage to double-check, you already know the awkward part. The remaining allowance is not one number. It is at least two windows, they do not always reset together, and official docs point you at more than one place to read them.

A macOS menu bar meter is a small UI on top of that problem. The interesting work is reconstructing a trustworthy reading from a session the provider already gave you, then deciding what to show when the reading is incomplete, stale, or about to change. This post is about that plumbing. I'm citing official provider docs for how the limits work, and the public docs of CodexBar, Peter Steinberger's MIT-licensed macOS 14+ menu bar app, as an open-source reference for how a meter fetches them.

The limit is a set of windows, not a tank

OpenAI's help center is explicit about Codex and ChatGPT Work on plans that have both constraints: usage limits "may apply over a five-hour window and a weekly window," and "where both apply, you need allowance remaining in both to continue." A new five-hour window starts with your first message after the previous window ends, and you can fill it "before five hours have passed, even if you still have weekly usage remaining." Check remaining allowance and reset times in Settings → Usage. The percentage is not a message count either. Your allowance "does not correspond to a fixed number of messages or tasks." How far it goes depends on the model, the task, and the settings. (Managing usage with GPT-6 Astra in Work and Codex) In the Codex CLI, /status shows "the chat ID, context usage, and rate limits." (Developer commands) OpenAI's resets guide also describes a /usage command in the Codex CLI for redeeming a banked reset. (How resets work in Codex)

Anthropic describes a similar shape for paid Claude plans: "a session limit that resets every five hours, and weekly limits that reset once every week." The five-hour period starts with your first message and "resets in full five hours later." Weekly limits reset at a fixed time each week assigned to your account. Usage on claude.ai, Claude Code, and Claude Desktop "counts towards the same usage limit." (How do usage and length limits work?) In Claude Code, /usage shows "session cost, plan usage limits, and activity stats." (Commands)

The windows are not universal. OpenAI currently says Pro 100, Pro 200, and Pro 500 have no five-hour usage limit in Work and Codex. Anthropic says verified Ultra accounts don't have a five-hour limit, and some plans also have a separate weekly limit for Fable. (Astra usage, Claude Code on Pro, Max, or Ultra) A meter that assumes every account has a five-hour bar will invent a window the provider does not report.

Reset times can also move. OpenAI documents banked, automatic, and purchased resets that restore covered allowances and can change the next refresh time without changing the billing date. On plans with both limits, "the same usage counts against the 5-hour and weekly allowances, but those periods can end at different times." Its example is a weekly period ending at noon while a five-hour period continues until 3 p.m., leaving you with a full weekly window and almost no session window. (How resets work in Codex) The honest display is "this window, this percentage, this reset time," not a single "you are fine until Friday."

The shape changes over time, too. As of mid-November 2026, OpenAI's help center says that starting in December, Plus, Pro, and Business usage will be shared across ChatGPT and Codex, measured in tokens, with remaining usage and reset times in Settings → Usage. Instant chat will not draw from that usage. (Understanding ChatGPT and Codex usage limits) A meter has to read what the provider reports now, not a hardcoded plan table. Context-window length is also a different kind of limit from usage: hitting a session cap means waiting or changing plan, while hitting a length limit means the current conversation is too large. Those should not be the same bar.

The hard part is the data source

None of that official data arrives as a single public "menu bar API." CodexBar's authoring guide describes the practical response: each provider is a descriptor plus a pipeline of fetch strategies (CLI, OAuth, API token, browser cookies, a local probe, a web dashboard), tried in priority order, with fallback when a strategy is unavailable. (Provider authoring guide) As of November 12, 2026, its provider overview says it registers 113 provider IDs, in part because one company can expose more than one surface with a different auth source and quota shape. (providers.md)

The data flow is straightforward: a background refresh runs provider probes, writes a snapshot into a store, and the menu, icon, and widgets read from that store. (Architecture) The interesting policy is how each probe gets a session without asking for a password. CodexBar's README puts it as reusing existing provider sessions (OAuth, device flow, API keys, browser cookies, local files) so "no passwords are stored."

For Codex, the documented Auto order is a personal access token if one is available, then the OAuth API using credentials already on disk at ~/.codex/auth.json (or $CODEX_HOME/auth.json), then a local CLI RPC server started as codex app-server, which exposes account/read and account/rateLimits/read. The app maps primary_window and secondary_window onto the session and weekly lanes. An optional OpenAI web dashboard path is off by default and is not an Auto fallback. Parsing the rendered /status panel in a Codex TUI is a manual diagnostic only, because a bare codex TUI "can start interactive auth and open browser tabs." Automatic refresh does not take that path. (docs/codex.md)

For Claude, the documented app Auto order is an OAuth usage API, then a Claude CLI probe, then a browser-cookie web API. The OAuth path reuses Claude Code credentials and maps five_hour to the session window and seven_day to the weekly window, only when those fields actually report utilization. The CLI fallback runs claude in a dedicated probe directory, sends /usage, and parses the "Current session" and "Current week" headers. A working Claude Code login or a signed-in browser tab does not, by itself, mean the meter can read that session. Some Education and organization-managed subscriptions return only a notice, with no numeric quota fields. In that case the docs say to report those limits as unavailable and never derive a percentage from spend or token totals. (docs/claude.md)

That last rule is the one I would keep even if everything else changed. If the provider did not give you a quota, you do not get to invent one.

Quota is not the same as cost

A second easy lie is turning a remaining-quota percentage into a dollar amount. CodexBar's docs draw the line directly: "Account quota and estimated API cost have different coverage." Remote quota can include work with no readable local token record, and "CodexBar cannot convert a quota percentage into dollars." Local cost scans, where they exist, read known session logs. The Settings → Usage & Spend view is "a local estimated-cost history page, not a billing receipt and not the menu-bar quota card." Amounts are list-price equivalents unless a source also reports plan-metered spend, and the app "never adds or ranks amounts across currencies." (docs/codex.md, providers.md) Keep those as two separate numbers, and say on screen which one the provider confirmed and which one is a local estimate.

How often to ask, and what to show when the answer is old

Limits move while you work, but polling every few seconds is a bad deal for battery, for rate limits, and for any provider that treats a usage fetch as a real request. CodexBar's refresh loop makes the tradeoff visible. Fresh installs default to Adaptive cadence, a function of recent menu interaction, Low Power Mode, thermal state, and, only in an opt-in "agent-aware" mode, recent local coding activity. Every decision lands between 2 and 30 minutes. Manual refresh is always available. Transient network failures keep the last successful snapshot and its original measurement time; authentication failures and account changes still invalidate it. Stale or error states dim the icon instead of pretending the number is fresh. (docs/refresh-loop.md)

Two other documented choices are worth copying. CodexBar does not redeem or modify Codex reset credits; it can list them and optionally warn before they expire, but the provider remains in charge of the allowance. And the permissions it asks for are narrow: optional Full Disk Access only to read Safari cookies or local storage, Keychain access when you import a Chromium session or repair Claude OAuth, and Files & Folders prompts when a launched CLI needs a working directory. It does not request Screen Recording or Accessibility in the background, and it does not store passwords. (README) A stale percentage with a capture time is more honest than a blank icon or a guessed refill.

Where TokenBar fits

We build TokenBar, a macOS 14+ menu bar app at Aura Technologies. It keeps AI usage, credits, costs, and reset windows visible across supported providers, and it is built on CodexBar. The public trust page states that the app's repository history descends from Peter Steinberger's MIT-licensed project and includes later contributor work as well as our changes. TokenBar also includes a Pixel Agents panel, powered by a local installation of Pixel Agents, a separate MIT-licensed project.

The site currently features Claude, Codex, Cursor, Gemini, and Copilot, and exact coverage varies by integration. Basic is $5 a month per Mac. Pro is $15 once, a lifetime license for one Mac. You download the app and choose a plan inside it. Provider subscriptions and API charges stay separate: TokenBar monitors connected tools, and it does not give you extra quota. If you only want limits and reset times in the menu bar, CodexBar is free, open source, and documents a much longer provider list.

What I would tell anyone building a meter

Model the windows the provider reports. Do not assume every plan has a five-hour session bar, and do not collapse session and weekly remaining into one "you are fine" state.
Keep quota and cost apart. A remaining percentage is not an invoice, and a local log scan is not a substitute for missing remote token records.
Reuse a session the user already has. OAuth files, a local CLI, or an opt-in browser session are enough to start. Store no passwords.
Prefer a stale snapshot with a timestamp over a blank, and over a fabricated number. If the provider returned no quota, show the limit as unavailable.

If you have built anything that reads these allowances, I'm curious about a narrower question than "which API is nicest." When the CLI and the website disagree on remaining quota, which one do you treat as source of truth, and how stale do you let a menu bar reading get before you hide it?