3 ms·

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 f

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.

vunderba 7mo ago
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.
- hombre_fatal 7mo ago
  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.
  - vunderba 7mo ago
    > 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.
    - hombre_fatal 7mo ago
      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.
      - vunderba 7mo ago
        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.
        hombre_fatal 7mo ago
        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.
        vunderba 7mo ago
        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.
        7mo ago
isjdiwjxiwj 7mo ago
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.
- hombre_fatal 7mo ago
  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.

vunderba 7mo ago

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.

hombre_fatal 7mo ago
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.
- vunderba 7mo ago
  > 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.
  - hombre_fatal 7mo ago
    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.
    - vunderba 7mo ago
      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.
      - hombre_fatal 7mo ago
        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.
        vunderba 7mo ago
        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.
        7mo ago

isjdiwjxiwj 7mo ago

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.

hombre_fatal 7mo ago
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.