Hacker News Reader

Comment by hombre_fatal | Hacker News Reader

I built my own macOS terminal app over the last two weeks using swift/appkit + ghostty's zig library.

I basically just wanted vertical tabs and notifications for when AI agents (claude code, codex) are finished.

I already use it as my main terminal over iTerm.

It's a fun project since I use my terminal all day, so I always have ideas for how something could be improved or polished. AI can do the chore work of figuring out how to impl some bugfix or UX polish, and I manage the last 10%.

This would have been too much work to maintain for fun before LLMs.

View on HN

FWIW most of the agentic CLI tools also let you setup notification hooks so you can just do something like this:

  afplay /System/Library/Sounds/Glass.aiff                                                    
  osascript -e 'display notification "Waiting..." with title "Coding Agent"

The sound is especially useful since for longer running tasks I'll often do some chores around the house while waiting for it to finish up.

My notification hook pipes an OSC 777 (title, body) message into /dev/tty, Ghostty handles/ingests it and then emits the event for my terminal app to do things like craft a macOS notif and style the tab/pane of the originating terminal.

    #!/usr/bin/env bash
    MSG=$(cat | jq -r '.last_assistant_message // empty' | head -c 200)
    printf '\e]777;notify;Claude Code;%s\a' "${MSG:-Claude finished responding}" > /dev/tty

I tried the osascript solution first but had some issues, iirc no good way to focus the originating terminal pane on notif click.

Something I never figured out is why Claude Code's "Notification" hook waits minutes to fire. I had to use the "Stop" hook for actual end-of-response timing.

> iirc no way to focus the originating terminal pane on notif click.

Yeah mine has the same issue - it just brings up the script editor. It's not as much of an issue for me since I'm rarely running more than a single Opencode instance at a time.

Could definitely see that being useful if you were running quite a few agents to let you hone in on the correct terminal window/tab quickly though.

Yeah, exactly. I have so many agents running these days. 1-2 per project.

Often one is polishing a plan file for the next feature/bugfix (claude), and the other is reviewing it to give feedback (codex). And that is my life now. But on the upside, it's trivial to maintain sideprojects now.

Nice. You have a similar setup to mine. I've found OpenAI's gpt-5.3-codex (at xhigh) to be pretty dismal at actual implementation but it's surprisingly adept at performing a high level feature branch review and catching issues that are missed by Gemini/Claude.

Yeah, through trial and error I found that Codex (now gpt-5.4) has really good feedback once there's a plan file.

Kinda like someone on the internet who suddenly becomes an expert once you make concrete claims for them to shred into.

I have an AGENTS.md prompt that specifies how to review a plan. Something like: for every finding, rank the top solutions internally and then recommend a solution. And if there's a simpler, better pivot that the plan should take, pitch it at the end.

It's really actionable, and I basically can paste the review back into Claude, then tell Codex to re-review the plan, and repeat this until it has nothing more to add, and now I have a really good plan.

Nice. I have a similar loop (Opus 4.6 plan <-> Codex xhigh review) that I kind of run in an iterative feedback loop until meaningful actionables converge down to zero.

I initially gave some thought to automating this because CC/Codex do have SDKs... but every once in a while Codex will propose some absurdly over-engineered stack advice that I have to manually reject before passing it back to Claude.

Man, we are on the the exact same page.

Yeah, I also thought about automating it before. Especially when I'm middlemanning noncritical plans where I don't care what the solution is.

I did make a skill /ask-codex that gets Claude to call Codex for one round of feedback which is pretty useful.

But for critical plans, I suppose being the middleman gives me a good opportunity to learn about the solution and its trade-offs as it's being incrementally refined. Especially in a domain I don't know much about.

I hardly think you can say YOU built it went all your did was manage 10% of the project. An LLM built it, you just test it.

Figuring out what to build, how it should work at a high level, and what it should be like to use it is the hard part and the defining aspect of any tool or application. (Or a fun game, for example)

Now that the cost of writing code is ~$0, I think the entity who figures that out is the one who built it, not the entity that does the trivial chore once the hard decisions have already been made.

Reply on news.ycombinator.com