Early preview · v1.0.5 for Apple silicon Macs
Mastlight
Every Claude Code session, one calm board.
A Mac app that runs many Claude Code sessions in terminals it owns, across one account or several, and puts whichever one is waiting on you at the top.
- first commit to v1.0.5, around an engine I already ran daily
- 3 days
- scripted release-QA steps passed on the built DMG
- 15 / 15
- to answer a permission, plan or question
- 1 key
- telemetry or accounts; one daily update check you can switch off
- 0
The problem
Run enough Claude Code sessions at once, across terminal tabs and more than one account, and the costly moment is a session sitting silently on a permission prompt while you look at a different tab. Terminals were never designed to tell you which of fifteen windows needs you.
What it does
- Permission requests, plans and questions become cards you answer with a key. One inbox, oldest first; ⌘J jumps to the next one.
- Sessions from several accounts share one list, with each account's 5-hour and weekly usage in view.
- Close the window and sessions keep running. Sessions already open in Terminal, iTerm or tmux can be moved in.
- Runs on your Mac: no account, no telemetry, and the app never sees a credential.
Decisions that shaped it
Own the terminals instead of scraping them
Electron with node-pty and xterm.js, the same terminal stack VS Code uses. A headless mirror of every screen makes reads exact, and sessions outlive the window. Tauri was ruled out because the machine had no Rust toolchain.
Answer through Claude Code's own hooks
The hook that drives the cards is passed to each session on its command line, so the user's own Claude settings are never edited. That set a floor of Claude Code 2.1.85, the first version where a hook can answer a question.
One decision per card, on purpose
There is no approve-everything button. A tool that makes approving faster should not also make it careless.
Never hold a credential
Accounts are added by running Claude's own /login in a terminal inside the app. Mastlight reads only the email and plan from each account's config.
Cut scope rather than ship it half-right
Phone access was struck from 1.0 to rethink the approach. Its code stays in the tree, unreferenced, with tests that fail if any of it becomes reachable.
Be plain about distribution
The build is not yet signed by Apple and the site says so, with the exact steps. The app checks a feed once a day and opens a browser; it never downloads or installs anything itself.
Another look
How it was built and checked
- Built as a graph of bounded loops: each node has a written contract and acceptance checks, and work is reviewed by a separate verifier rather than the agent that built it.
- A scripted release QA runs against the built DMG, not a dev build.
- Guard tests pin the things that must never happen, such as reaching the removed phone feature.
- The marketing site scores 97 to 100 in Lighthouse and has zero axe violations in both themes.