DEV Community: Aaron Sun

Three small open-source Mac tools for working next to AI coding agents

Aaron Sun — Wed, 11 Nov 2026 21:41:26 +0000

These days most of my coding happens with several Claude Code sessions running at once, plus a browser the agents sometimes need to use. Three things kept costing me time, so I built three small tools for them. They're free, MIT-licensed, and as of today public.

Pullbell: a GitHub inbox in the menu bar

Review requests and comments on my PRs got lost in email, and with agents opening PRs for me there are more of them than ever. Pullbell sits in the macOS menu bar and raises a banner only for the things that need me: someone requests my review, comments or replies on my PR, approves it or asks for changes, a PR becomes ready to merge or gets a conflict, a deploy on the default branch fails. Everything else (bots, CI runs) goes into a quiet list.

⌃⌘G opens a searchable queue, ⌃⌘P my open PRs and the ones waiting for my review, with CI and review state.
Watch everything, or only the repos of the teams you pick; mute the noisy ones.
Signs in with GitHub's device flow; the token lives in the macOS Keychain.

https://pullbell.zexa.se · https://github.com/aaronsuns/pullbell

Hopback: which Claude Code session needs me?

With five or six VS Code windows each running a Claude Code session, the question is always "which one is waiting for me?" Hopback answers it from the menu bar: ⚠1 ⚙2 · ▢8 means one session waits for an approval or an answer, two are working, eight windows are open.

A small Claude Code plugin (hooks) tells Hopback when a session starts working, finishes, or waits for you, and you get a banner.
⌃⌥1–9 jumps to a window, ⌃⌥0 to the next session that needs you.
⌃⌘C searches open sessions, ⌃⇧⌘C searches your whole history, including the conversation text. Type ? and a description and it asks Claude (read-only tools) to find the session you mean.

https://hopback.zexa.se · https://github.com/aaronsuns/hopback

Tabrelay: let an agent use your real Chrome

Headless browsers are great until the site needs your login. Tabrelay is a small Chrome extension plus a CLI that lets a script or an AI agent drive your real, logged-in Chrome through the DevTools Protocol, without raising windows or stealing focus while you keep working.

TAB=$(tabrelay open https://example.com/)   # a background window; prints the tab id
tabrelay eval "$TAB" 'document.title'       # "Example Domain"
tabrelay shot "$TAB" page.png

Only sites on an allow-list you set in the extension's options (empty by default).
A local token, and requests from web pages are refused.
Includes example scripts for posting to a few social sites, with a disclaimer: what you automate is your responsibility, and each site's rules apply.

https://tabrelay.zexa.se · https://github.com/aaronsuns/tabrelay

How they're built

Pullbell and Hopback are Tauri 2 apps (Rust + a small React UI), universal builds for Apple silicon and Intel, with signed auto-updates from GitHub releases. Tabrelay is a Manifest V3 extension and a single-file Python CLI. All three have CI and tag-driven releases.

They aren't notarized yet (no Apple Developer ID), so the first launch needs one xattr command; the READMEs show it.

About AI: I designed these and wrote the specs; most of the code was written by Claude Code under my direction, then reviewed and tested by me.

If you try one, I'd love to hear what's missing or confusing — issues on GitHub are the best place.

I'm still learning Swedish, so I built a dual-subtitle extension for Nordic public TV

Aaron Sun — Wed, 11 Nov 2026 00:50:17 +0000

I'm a developer living in Sweden, and I'm still learning Swedish. The best practice material I've found isn't a course: it's public TV. SVT Play, UR, NRK and DR have huge free libraries, and almost every programme comes with subtitles in the original language.

The problem is the player. It shows one subtitle track at a time, and there is no subtitle in my language. Swedish-only subtitles are too hard at the start, and pausing to look things up kills the flow. Tools like Language Reactor solve this for Netflix and YouTube, but not for the Nordic broadcasters. So I built Nordic Dual Subs: a free browser extension that shows the broadcaster's own subtitle line together with a translation in your language, perfectly in sync.

What it does

Two lines at once on SVT Play, SVT Barn, UR Play, NRK TV and DR TV: the original Swedish, Norwegian or Danish line, and a translation (29 languages, including Arabic, Persian, Somali, Tigrinya, Ukrainian and Chinese, right-to-left included).
Click any word: the video pauses and you get the meaning and the base form (sprang → springa), with an English gloss from the open Folkets lexikon dictionary.
Save words with their sentence, review them with simple spaced repetition, or export them to Anki as CSV.
Practice keys: A / S / D for previous / repeat / next line, Shift+S replays the line slowly.
Burned-in subtitles: some foreign films have the Swedish text in the picture. The extension reads it locally with Tesseract (WebAssembly) and translates it.

How it works (the parts that were interesting to build)

Getting the subtitles. Each broadcaster exposes its subtitle files (WebVTT and friends) through the same APIs its own player uses. The content script works out which programme is playing (all five sites are single-page apps, so it follows URL changes), the background worker fetches and parses the subtitle file, and an overlay is drawn inside the site's own player so it also works in fullscreen. The site's own subtitles are hidden so nothing overlaps.

Translation without a translation bill. I wanted this to run at zero cost. Each browser translates lines with Google's free web endpoint from its own IP, and sends [line, translation] pairs to a small backend. A line becomes trusted only when installs from two different networks submitted the identical translation (Google is deterministic, so honest clients agree, and one client can't plant a translation). Trusted lines are then served to everyone, keyed by a hash of the line, so the server never hands out subtitle text to someone who doesn't already have it. When Google rate-limits a user, a capped DeepL fallback covers the lines near the playhead.

The backend is Cloudflare's free tier. One Worker plus a D1 (SQLite) database: anonymous installs with HMAC session tokens, the shared translation cache, optional Google sign-in for syncing saved words, and Stripe for a future optional Pro plan. Free tiers have hard daily limits, so a small GitHub Action checks D1 and Workers usage every morning and mails me before anything gets close. One lesson: my end-to-end tests were quietly writing thousands of rows to the production database. They now run against an in-process mock API, with a guard that fails the test if anything tries to reach production.

One codebase, three stores. The same source builds a Chrome/Edge package and a Firefox package. The Firefox build swaps the MV3 service worker for background scripts, drops the offscreen API (OCR runs in Firefox's background page instead, which has a DOM), and declares Firefox's data-collection consent. Firefox for Android gets touch controls (⏮ ↺ ⏭ 🐢) instead of keyboard shortcuts. Publishing goes through each store's API, with one catch: Microsoft only lets the API publish an Edge extension after its first version was published by hand.

Things outside my control. DR TV only plays when you're logged in, and some programmes on all three broadcasters are geo-restricted to their own country. The first user email I got was exactly that: "it doesn't work on DR TV". The extension now says why (log in to DR, or "this programme is only available in Denmark") instead of staying silent.

Built with a lot of AI help

Full disclosure: I built this with heavy help from an AI coding assistant. It wrote much of the code and the tests, ran the end-to-end tests against real SVT and NRK programmes, and handled most of the store paperwork. I decided what to build, tested it on my own TV evenings, and pushed back when something was wrong. It's been a fun way to ship a side project in the evenings without cutting corners on tests.

Try it

It's free (everything is free during the launch period; the dual subtitles stay free), no account needed.

Website and guides (16 languages): https://dualsubs.zexa.se?utm_source=devto&utm_medium=article&utm_campaign=launch
Chrome Web Store: https://chromewebstore.google.com/detail/ejmbcllddngiakhpcpajkajeghmdapko?utm_source=devto&utm_medium=article&utm_campaign=launch
Edge and Firefox (desktop + Android) versions are in store review right now.

If you're learning a Nordic language, I'd love to hear what's missing. And if you've built something similar for other broadcasters, I'm curious how you handled subtitles and translation costs.

I replaced Spotify for my family with a music server I built, and its own phone apps

Aaron Sun — Tue, 10 Nov 2026 20:29:04 +0000

I ran Navidrome at home for a long time. The server was never the problem. The phone was: every client I tried had its own bugs, and they always showed up in the same two places, playing in the background and playing in the car. My family uses music mostly in the car and on walks, so "it works when the screen is on" wasn't good enough.

So I built my own server and its apps together, and called it Melarka. It has replaced Spotify for us. This post is how it's put together and what I learned. It's open source (AGPL-3.0): github.com/aaronsuns/melarka.

AI disclosure: Melarka was built with a lot of help from Claude Code, and this post was drafted with Claude too. I designed it, steer it, review what goes in, and test it on our phones every day.

What it does

Your folders, untouched. Point it at the music you already have. It never rewrites files or tags; titles, tags, lyrics and fixes live in its own database.
An account per person. Everyone at home gets their own favorites, playlists, personal radio and nightly picks.
Synced lyrics, and anyone can nudge lyrics that run early or late.
Native apps. An Android app in Kotlin and an iPhone app: background play, lock-screen and car controls, gapless, and an offline cache of favorites.
Car autoplay. When the phone connects to the car over Bluetooth, the favorites start playing by themselves, and the current lyric line shows on the car's display.
Optional YouTube. Search YouTube or follow channels, and download songs into your own library with yt-dlp.

How it's built

The server is one Go binary with SQLite, shipped as one Docker container. Install is one command:

curl -fsSL https://raw.githubusercontent.com/aaronsuns/melarka/main/deploy/install.sh | sh -s -- /path/to/your/music

It streams the original file, or transcodes to AAC on the fly with ffmpeg when the phone needs it.

The web app is React. The phone apps are a mix that turned out to be the main design decision: the screens are the server's own web app, and playback is native. The page sends "play this queue" to the native side over a small bridge; the native player (Media3 on Android, AVFoundation on iOS) owns the audio, the lock screen and the car.

That split is why it works in the car. The web page can die, the screen can be off, the app can be in the background, and the music keeps going, because nothing about playback depends on the page. And every new server feature shows up in the apps on day one, because the screens come from the server.

Things that took the longest

Never starting music on its own. A player that resumes when a Bluetooth device connects is a nice feature in the car and a terrible one at 6 a.m. in a quiet house. The rule now: only a person (or the car autoplay they turned on) starts sound, and there are tests for every path that can start playback.
Offline that actually works. The favorites are cached on the phone and the player falls back to them when the network goes, instead of stopping or skipping through the whole queue.
Emulator tests in CI. The Android app has an end-to-end test on an emulator against a real server: sign in, play a favorite, kill the page's renderer, background the app, go offline. Keeping that test reliable on CI machines was its own project.

The honest catch

Melarka has its own API, so it is not Subsonic-compatible: your existing Subsonic clients won't work with it, and it only makes sense if you want its apps. It's also young, about a month public. The Android APK is on the GitHub releases page (F-Droid is submitted but waiting until the app is older), and the iPhone app installs with SideStore, not the App Store.

If you run a home server and your family still pays for Spotify, I'd love to hear what you think, and especially what breaks. A one-minute tour is on melarka.zexa.se.