Developer Puts Claude Code and Codex Agents in the MacBook Notch, at 0.5% CPU

Three or four parallel Claude Code and Codex sessions quickly turn a workday into a scramble between windows: one agent has finished, a second is waiting for confirmation, a third has hung. The author of a Habr write-up solved this with a small macOS app. It shows the status of every agent in the MacBook notch and makes the notch glow when someone needs a human. The app draws each session as a little figure in a pixel-art office. According to the author, the glow costs about 0.5% of CPU.

The problem: many agents and no control panel

Running coding agents in parallel has become routine. One refactors a module, another writes tests, a third tracks down a bug. The tooling for this is still built around a single terminal window and one person looking at exactly that window. If an agent stops to wait for permission to run a command, it sits idle until you notice. On long tasks, these pauses add up to hours.

The notch is a logical choice here. It is the one area of the screen that windows do not cover, and it is always in your field of view. The app uses empty space and does not compete with the editor for room.

How it works

For Claude Code, the author uses hooks. This mechanism runs your own commands on session lifecycle events, such as a stop or a request for attention. The app receives a signal at the moment of the event and does not poll processes in a loop.

Codex works differently. The author reads the session logs the tool writes to disk and does without an API. The approach is pragmatic, but it comes with a caveat: the log format is not a public contract. A Codex update may change the file structure, and the parser would then need fixing.

The visual part is built from two layers:

• the pixel-art office is rendered in SpriteKit, with one session corresponding to one figure;
• the notch glow is built with Core Animation rather than by constantly redrawing a scene.

The second point explains the 0.5% CPU figure. An animation driven by the system compositor is cheaper than frame-by-frame rendering. For an app that stays open all day, this matters a great deal. An indicator utility should not eat resources away from the agents and the IDE.

Key parameters

• Platform: macOS, the MacBook notch area.
• Claude Code: status arrives via hooks.
• Codex: log reading, no API.
• Visualization: pixel-art office in SpriteKit.
• Waiting signal: Core Animation glow, about 0.5% CPU.
• Statistics: the author says he collects them without a single counter inside the app. He gives the details in the full article.

What you can put to use

If you run several agents at once, you do not have to start with the notch. A minimal version fits into a single evening: a Claude Code hook on the stop event writes the status to a file or sends a system notification. Even that removes half of the window checking.

Next, decide what to trust. Hooks are better than log parsing because they are a documented extension point. Logs are handy when a tool has no clear event, but budget time for maintenance. If you read the files of someone else's CLI, keep a format check in place and show a parse error in the interface, rather than silently assuming the agent has hung.

There is a separate lesson about resource use. Any background indicator for agents that already load the CPU and memory should stay within fractions of a percent. It is better to hand animation to the system compositor than to redraw the scene every frame.

The pixel-art office can be treated as decoration, but it has a practical purpose. A figure at a desk, a figure by the coffee machine and a figure with a raised hand are easier to read than a table of statuses. For developers of agent tools, this project points to what the products themselves lack: a stable stream of session-state events that does not have to be extracted from logs.