Native macOS companion for Claude Code. A floating retro pager that shows you what Claude is doing so you stop babysitting your terminal. Real-time LCD status with pixel art animations Four auto-accept modes (Strict / Relaxed / Trusted / YOLO) Voice input and spoken recaps Hotkeys, always on top Customisable themes, size, voice 100% local. Zero dependencies. Open source.
Hey PH,
I'm a designer who uses Claude Code every day. I kept getting distracted by other work and coming back to find Claude had been waiting for a permission or had finished ages ago.
So I vibe coded a floating retro pager that sits on my desktop. Started as a simple status monitor but it grew: permissions, voice input, spoken recaps, hotkeys, four auto-accept modes. I'm a designer so I had to go hard on the design: retro skeumorphic, 10 themes, pixel art animations, 3 sizes, etc.
Even added a useless but fun little feature: double clap to start dictating (enabled in the settings).
Everything runs locally. 100% Swift, zero dependencies. No accounts, no telemetry, no API keys. Just download and use it.
First open source project, for sure imperfect, but I use it every day and wanted to share it. Ideas and feedback are welcome.
https://github.com/vecartier/cc-...
brew install --cask cc-beeper
@vecartier Love it! Damn, I'm a sucker for good designers who divine it and ship products. Apps like this make digital interactions more alive, vibrant - nice job Victor ;).
Can you walk through how the blocking PermissionRequest hook handling works end-to-end (especially holding a TCP connection open) and what reliability/edge cases you had to solve—multiple concurrent sessions, crashes, sleep/wake, terminal restarts, or Claude updates?
@curiouskitty Hey, I'll try to answer this the best I can (with claude's help) since I'm not technical. It was mostly trial and error, prompting Claude Code to fix issues / change the way it works to my satisfaction. I should add that I ask a couple developer friends to check if it had any glaring security issues or problems, but so far they didn't spot any.
Claude Code's blocking hooks are basically an HTTP call that waits for a response. CC-Beeper runs a tiny local server, and when a permission request comes in, it just keeps that connection open while the widget asks you what to do. When you click Allow or Deny, it writes the answer back on that same open connection and closes it. Curl gives it around 55 seconds to respond before it gives up.
Re, the reliability stuff:
- Multiple sessions: pending prompts queue up in order, so answering one surfaces the next.
- Session moved on (you answered in the terminal instead, or Claude auto-resolved): it detects it from the next hook event and quietly releases the stuck prompt.
- Claude Code or CC-Beeper crashing: connections get cleaned up on drop, and a 5-minute watchdog resets the UI as a backstop.
- Restarts and Claude updates: the hook config in settings.json reads the port fresh every time, so nothing's baked in. If CC-Beeper isn't running, the hook fails cleanly and Claude falls back to its normal terminal prompt, so you're never locked out.
- Sleep/wake: honestly the weakest spot today. No explicit handler, stuff just times out and recovers.
It's probably imperfect, and if someone more technical / knowledgeable than me knows and want to improve it, it'd be amazing. That's also why I made it open source :)
Report
This fills a real gap - I've caught myself staring at the terminal waiting for Claude to finish way too many times. The four auto-accept modes are the right call, YOLO mode for scaffolding and Strict for anything touching prod. One question: does the LCD status show which tool Claude is currently using (file read vs bash vs edit)? That granularity would be genuinely useful for knowing when to intervene.
@razazu it does / should to an extent. But it’s not perfect. The form factor is limited because of space on the LCD.
I think there needs to be a balance between showing too little and too much.
My reasoning was that showing too much is kinda pointless because you might as well go check the full terminal. Show too little and it gets kinda risky.
I should add that I’m not technical so I don’t 100% what all the permissions mean when I accept them. But since I only do this in my spare time on low stakes side projects, it’s not that big of deal.
Report
@vecartier That balance makes total sense - the whole point is to not babysit the terminal, so cramming too much on the LCD defeats the purpose. The "just enough to know when to intervene" approach is the right call. Appreciate the honest answer on the permissions side too, that kind of transparency is rare.
@vecartier to be honest I would love it if anthropic / Claude code theme did it natively.
Or someone more technical than me took over the project or jammed on it with me.
At the end of the day, I’m not trying to compete with anyone or sell anything. Just love using Claude code and wanted to make my life easier (and maybe other people’s).
Report
When you have multiple Claude sessions running at a time, do we get multiple pages, or does the page screen get increased with each Claude session?
@nayan_surya98 So you keep one beeper at all times but it works across sessions. What i tried is creating a priority order between states across sessions (e.g. needing a permissions supersedes working/done state for another). But it's far from perfect. Honestly, I lack the technical skills to go the extra mile and I want it to remain a fun week-end project :)
I’ve run into this myself—I often assume Claude would’ve completed the task by now, but when I check, it’s usually stuck on some permission issue. Love the idea—how do you detect when Claude needs permission? Do you poll for it continuously?
@samir_tawadros it should be but I’m not 100% sure. It uses hooks and settings.json. As long as that’s there, it should be fine !
Report
The four auto-accept modes are the interesting design decision here. YOLO mode — does that mean Claude can execute shell commands, write files, make network requests without any prompt? Trying to understand where the trust boundary actually sits, because "auto-accept everything" in an agentic coding context is either brilliant or terrifying depending on what Claude decides to do at 2am.
CC-BEEPER
Unabyss
@vecartier Love it! Damn, I'm a sucker for good designers who divine it and ship products. Apps like this make digital interactions more alive, vibrant - nice job Victor ;).
CC-BEEPER
@dominik_bartosik Thank you so much, it really means a lot
Product Hunt
CC-BEEPER
@curiouskitty Hey, I'll try to answer this the best I can (with claude's help) since I'm not technical. It was mostly trial and error, prompting Claude Code to fix issues / change the way it works to my satisfaction. I should add that I ask a couple developer friends to check if it had any glaring security issues or problems, but so far they didn't spot any.
Claude Code's blocking hooks are basically an HTTP call that waits for a response. CC-Beeper runs a tiny local server, and when a permission request comes in, it just keeps that connection open while the widget asks you what to do. When you click Allow or Deny, it writes the answer back on that same open connection and closes it. Curl gives it around 55 seconds to respond before it gives up.
Re, the reliability stuff:
- Multiple sessions: pending prompts queue up in order, so answering one surfaces the next.
- Session moved on (you answered in the terminal instead, or Claude auto-resolved): it detects it from the next hook event and quietly releases the stuck prompt.
- Claude Code or CC-Beeper crashing: connections get cleaned up on drop, and a 5-minute watchdog resets the UI as a backstop.
- Restarts and Claude updates: the hook config in settings.json reads the port fresh every time, so nothing's baked in. If CC-Beeper isn't running, the hook fails cleanly and Claude falls back to its normal terminal prompt, so you're never locked out.
- Sleep/wake: honestly the weakest spot today. No explicit handler, stuff just times out and recovers.
It's probably imperfect, and if someone more technical / knowledgeable than me knows and want to improve it, it'd be amazing. That's also why I made it open source :)
CC-BEEPER
@vecartier That balance makes total sense - the whole point is to not babysit the terminal, so cramming too much on the LCD defeats the purpose. The "just enough to know when to intervene" approach is the right call. Appreciate the honest answer on the permissions side too, that kind of transparency is rare.
CC-BEEPER
@razazuBest policy there is in my book :)
CC-BEEPER
When you have multiple Claude sessions running at a time, do we get multiple pages, or does the page screen get increased with each Claude session?
CC-BEEPER
@nayan_surya98 So you keep one beeper at all times but it works across sessions. What i tried is creating a priority order between states across sessions (e.g. needing a permissions supersedes working/done state for another). But it's far from perfect. Honestly, I lack the technical skills to go the extra mile and I want it to remain a fun week-end project :)
Badge
I’ve run into this myself—I often assume Claude would’ve completed the task by now, but when I check, it’s usually stuck on some permission issue. Love the idea—how do you detect when Claude needs permission? Do you poll for it continuously?
CC-BEEPER
Badge
@vecartier This makes sense. Beepers look so vibrant. Thank you!
As a Claude Code user- this is clever. Does it work with the new agent/skill features too?
CC-BEEPER
The four auto-accept modes are the interesting design decision here. YOLO mode — does that mean Claude can execute shell commands, write files, make network requests without any prompt? Trying to understand where the trust boundary actually sits, because "auto-accept everything" in an agentic coding context is either brilliant or terrifying depending on what Claude decides to do at 2am.