AURORA, under construction: the cat in the notch that tells me when my AI agents need me

The problem: many sessions, no visibility

The vision fits in one sentence of the PRD: open AURORA and know in ten seconds which agents need me, how each project is going and what I have to do today.

Before AURORA, that information lived in three places that didn't talk to each other: each agent's terminal, each project's notes and a task list with no fixed home. To bring order to it, AURORA starts from five principles:

1. Local first, shared only if I choose so.
2. It observes, never decides for an agent.
3. A small data model.
4. It never writes inside other projects.
5. It never blocks an agent.

What already works: an island in the notch

Phase 1 lives where I already look: the MacBook's notch. A black island, compact while everything is fine, that expands when an agent needs something. Open it and every session is grouped by what it needs from me: waiting for you, working and recent.

The summary groups sessions by what they need from me. Each project has its colour, and the mascot changes pose with the status.

When an agent asks for permission to run a command, the island shows the exact command and lets me answer right there. If I don't reply within 60 seconds, the request goes back to the terminal: AURORA never leaves an agent hanging on the app.

Answering from the alert: the command in plain sight, two buttons and a clear deadline before falling back to the terminal.

While an agent works, the island shows what it is doing: the file it is editing, the change in progress and the completed steps.

And when I'm not looking at the screen, a system notification with action buttons does the same job:

Around that sit small pieces that make the difference in daily use: global, per-agent or per-project mute; a custom cat sound; a private seven-day history; launch at login; session and subagent names, and the ability to open the right editor even when the session runs in the background.

How it works inside

An event's journey is short and deliberately boring:

1. The agent fires its hook (Claude Code, Codex and the Antigravity CLI each have one).
2. A small binary, aurora-hook, receives the event and passes it through an adapter specific to each agent.
3. The adapter normalises it into a common contract of 12 event types.
4. The event travels over a local socket to the app, which moves the session through a 7-state machine.

The rule in charge is the fifth principle: never block an agent. The hook always exits successfully, has a 200 ms limit and only relays an answer after I click. Measured on a release build, 95th-percentile latency stayed between 7.3 and 10.6 ms, against limits of 20 ms with the app closed and 50 ms with it open.

Two more rules complete the privacy picture: in phase 1 the app doesn't use the network at all, and it never records prompt content.

Installing the hooks follows the same philosophy. AURORA backs up the agent's configuration file, shows the exact change before writing and only writes if the file hasn't changed since the preview. Uninstalling leaves everything as it was.

Answering from the alert, and where you still can't

Before designing the interaction, a spike checked what each agent actually allows. The result isn't uniform, and the interface reflects it instead of hiding it:

Aurora, the mascot

AURORA has a face: a white cat with black eyes drawn from Kron, the black cat of my research assistant. It has 19 poses that follow each session's status: resting, working, question, permission, finished, usage limit, error, crashed session, sleeping…

The mascot communicates status before the text does: at a glance I know whether something is waiting or all is well.

Animating it was also a performance decision. With Core Animation, the animated mascot used 0.00 s of CPU over 10 seconds; the same animation with SwiftUI's TimelineView took between 2.9 % and 4.1 %. For something that is always on in the notch, that difference matters.

Decisions already made

• SwiftUI and AppKit instead of Tauri and React, even though almost all my ecosystem is web. An app that lives in the notch, the menu bar and system notifications has to be native.
• A compiled hook, not a script. Codex approves hooks by the hash of the command, so the command has to stay stable. A binary does; a changing script doesn't.
• No Xcode project. The app is packaged straight from Swift Package Manager with a script, signed with a stable local identity.
• SQLite for what comes next. It is decided for phase 2, but phase 1 doesn't need it and doesn't use it.

How I'm building it

AURORA is also a method experiment. The rule is no code without an approved spec: every story starts as a specified change, the design lives in a DESIGN.md guarded by token tests, and the coding agent chains one story per commit and only stops to ask for approvals, live tests, spending or publishing. It is the same approach I described in Dexter.

Every story closes with me testing the installed app, not a demo. Phase 1 numbers, from 4 to 14 October 2026:

• 48 commits and about 10,200 lines of Swift across code and tests.
• 180 tests, growing from 54 to 99, 139 and 180 over four working days.
• 23 stories in the phase 1 epic (22 closed), 22 archived specified changes, 3 architecture decisions and 3 spikes.

What comes next

The roadmap has eight phases. The first five are approved; the last three have an approved direction and open questions.

Some decisions are still open and I won't pretend otherwise: whether to adopt macOS's Liquid Glass material, notarization (which requires Apple's paid developer program) and eight questions for phases 6 to 8, from where the server will live to which currency spend is measured in.

The next milestone is closing phase 1's last story with its live test and starting phase 2 with its own short PRD. When project cards work, this article will get its second instalment.

Frequently asked questions