LiveIsland: the Mac notch as a status bar for your coding agents

If you run two or three Claude Code or Codex sessions at once, you spend a surprising amount of time switching windows just to see which one is waiting for you, and whether you are about to hit the 5-hour limit. LiveIsland puts that answer in the one strip of the screen you were not using: the MacBook notch.

It is an MIT-licensed Swift app by Aissam Irhir that turns the notch into something like the iPhone's Dynamic Island: what is playing, your agent sessions and their limits, calls, AirPods, timers and the calendar. The features are pleasant, but the reason it is worth reading about is how it gets its data. Almost none of it comes from a proper API. It reads files the tools already write, hooks the one place Claude Code exposes its usage, and works around a macOS lock-down for media. Those are techniques you can reuse.

What it puts in the notch

The island opens on hover or click and closes when the pointer leaves; clicks anywhere else pass straight through. It has four pages you can reorder: Media, Agents, Activity and Accounts. When it is closed, the notch shows whatever matters most, and the priority is explicit: a call beats an agent that needs you, which beats music. Two things can share the closed island, so a running session and the waveform sit either side of the notch.

• Agents: every Claude Code and Codex session with its state (working with a timer, needs you, done, idle), a jump to the exact editor window or terminal tab, and the command to resume it.
• Limits: rings for Claude Code's 5-hour and weekly usage, the same for Codex, plus tokens used in the current window and today.
• Media: any app that plays audio, with direct support for Spotify and Music so a paused Spotify stays one tap away while a browser video plays.
• Activity: call timers for FaceTime, Zoom, Teams, Slack and others, which app holds the microphone, whether the camera is on, AirPods battery, timers and the next calendar events.

It also registers liveisland:// links (open a page, start a five-minute timer, check for updates), so Shortcuts and scripts can drive it. On Macs without a notch the island simply sits at the top of the screen.

Where each piece of data comes from

Most of LiveIsland is not UI work; it is finding where each tool already writes down what it knows. The README's own table lists every source, and it is worth reading as a map of what an unsandboxed Mac app can observe without asking another program for anything.

Agent sessions are just files being appended to

Claude Code keeps its transcripts under ~/.claude/projects, and Codex keeps its sessions under ~/.codex/sessions. LiveIsland watches both directories with FSEvents and works out each session's state from what was written last. The detail that makes this practical is in the README: transcripts can run to gigabytes, so it only reads the bytes that are new since the last look. The test suite reflects how many ways that can go wrong — appends, truncated files, files replaced under it, duplicate messages.

Jumping to a session uses a different source. The process table tells LiveIsland each agent's working folder and terminal, and which application sits above it, so it can raise the right window in VS Code, Cursor, Windsurf or Antigravity, or the exact tab in Terminal or iTerm2.

Usage limits come in through the status line

Token counts can be rebuilt from transcripts, but the real percentages of the 5-hour and weekly limits cannot. According to the snippet's own comments, Claude Code passes them only to your status line command, as JSON on stdin under rate_limits, and stores them nowhere else. So LiveIsland asks to add three lines to your status line script, right after it reads its input into $input:

# LiveIsland: share Claude Code's usage limits with the island (delete these lines to stop).if limits=$(printf '%s' "$input" | jq -c 'select(.rate_limits != null) | {observed_at: now, transcript_path, rate_limits}' 2>/dev/null) && [ -n "$limits" ]; then  printf '%s\n' "$limits" > "$HOME/.claude/liveisland-limits.json.tmp" && mv -f "$HOME/.claude/liveisland-limits.json.tmp" "$HOME/.claude/liveisland-limits.json"fi

Two small choices make this robust. It writes to a .tmp file and then renames it, so the island never reads a half-written JSON file: a rename within one filesystem replaces the old file in one step. And it records transcript_path with each reading, which is how LiveIsland later attributes the numbers to the right account after you switch, rather than guessing. Without these lines the island still shows token totals counted from transcripts; you just lose the percentages.

Several accounts, and what switching touches

The Accounts tab lists every Claude Code and Codex account used on the Mac, with plan, 5-hour and weekly usage and reset times, and stars the one with the most room. When the account in use runs out, the notch says so. It never switches by itself: you tap Switch, and how that works for Claude is a setting with three modes.

Codex switching is separate and also off by default; when enabled, LiveIsland keeps private copies of ~/.codex/auth.json per account in its own Application Support folder. Running sessions keep the login they started with, so a switch affects new sessions only. The README warns against /logout and codex logout, which can invalidate the saved login you are leaving, and against running two switchers at once, since each keeps its own copy of every credential.

Be clear about the trade here. With switching on, a third-party app holds working OAuth credentials for every account you have used. They sit where Claude Code and Codex already keep theirs, which is reasonable, but it is still more copies of a secret than you had before. Leaving the default on Off costs you only the one-tap switch.

Now playing, after Apple closed the door

The private MediaRemote framework is how notch apps have long read what is playing from any app. The README says that since macOS 15.4 only Apple-signed processes may read it. LiveIsland's answer, from the bundled mediaremote-adapter (BSD-3-Clause), is to run the adapter inside /usr/bin/perl, which is an Apple-signed binary. It works today; it is also exactly the kind of workaround a future macOS update can close, so treat the generic now-playing feature as the fragile part of the app.

Spotify and Music get a sturdier path: their own track-changed notifications, with AppleScript for details and controls. LiveIsland never scripts an app that is not running, because sending an Apple event to a closed app launches it.

The waveform is a Core Audio process tap on what the Mac is playing, available from macOS 14.2, active only while music plays and the bars are visible. It measures the signal band by band in memory; nothing is recorded, changed or kept. Microphone and camera status come from Core Audio's process list and CoreMediaIO, which report whether a device is in use, not what it captures.

Keeping an always-on app cheap

An app that lives in the notch all day has to cost close to nothing when closed. The author's own measurements, on an M4 Pro with both agents running and Spotify playing, put the closed island under 1% of one core and the open one around 9% while drawing. The first read of 460 Claude Code transcripts (2 GB) took about three seconds in the background, and checking them again 16 ms. Those are one machine's numbers, not a benchmark, but the approach behind them is sound: spinners and waveforms are drawn by Core Animation rather than redrawn frame by frame, clocks tick once a second, and pointer movement far from the notch is ignored.

The project layout carries the same discipline. Package.swift declares a LiveIslandCore library holding the parsers and decisions with no UI or system access, an executable target for the app, and a test target against the core only. That split is why the tests can cover transcript parsing, 5-hour windows, stale limit notices, update version comparison and account bookkeeping without launching anything.

There is also an AGENTS.md and a CLAUDE.md in the root, and the latter has a nice touch of self-awareness: it tells the agent working on the code that its own session will show up in the island as working, and that this is expected rather than a bug.

Installing it, and the Gatekeeper question

It needs macOS 14 or later and runs on Apple silicon and Intel. The README's one-liner downloads the latest release into ~/Applications and opens it:

$ curl -fL https://github.com/charonova/LiveIsland/releases/latest/download/LiveIsland.zip -o /tmp/LiveIsland.zip && mkdir -p ~/Applications && ditto -xk /tmp/LiveIsland.zip ~/Applications && open ~/Applications/LiveIsland.app

$ git clone https://github.com/charonova/LiveIsland.git$ cd LiveIsland$ ./scripts/install.sh

Later versions come through Settings › Software Update, which checks GitHub at most once a day (you can turn that off) and never installs on its own. Before replacing the app, it checks the download's SHA-256, that it is LiveIsland at the promised version, and that codesign --verify passes. That last check confirms the bundle has not been altered since it was signed; without notarisation it does not, on its own, tell you who signed it.

macOS will ask for Calendar, Bluetooth (AirPods battery), Automation for Spotify, Music and your terminal, and system audio recording for the waveform. Every one is optional; refuse one and only the matching tile stays empty. Nothing is needed for agents or accounts. The privacy section states there are no analytics and no accounts, and that the only network calls fetch Spotify cover art and the daily update check.

Who it is for

If you spend your day with more than one coding agent running and keep glancing at usage pages, LiveIsland answers the two questions you actually have — which session needs me, and how much room is left — without a window switch. The media and call features are good, but other notch apps already do those; the agent tracking is what sets it apart.

It is also young. At the time of writing the repository has a single author, one star and no forks, with around 150 commits, so expect rough edges and read the release notes before each update. Even if you never install it, the code is a compact lesson in observing tools from the outside: watch the files they append to, read only the new bytes, write state atomically, and keep every parser in a module you can test without a screen.