Your meetings without leaving the terminal
The Mac that records your meetings is often not the one you are typing on, and a terminal reaches it like anything else.
listenr tui is Listenr in a terminal window, so it goes wherever a terminal goes. Over SSH, you can drive the Mac that is sitting in the meeting from the laptop in front of you. In a tiling window manager or beside your editor, the live transcript fills in next to your work instead of on top of it. Every note, transcript and command is reachable from the keyboard.
listenr tui
listenr tui --route live
listenr tui --route meeting 4f2a --pane transcript
What you can do in it
The screens match the app: library, meeting, live, calendar, settings and onboarding. o opens the same place in the Mac app when you want the window.
A meeting has five tabs:
- Details: title, time, platform, participants, kept audio, and notes status.
- My notes, editable.
- Transcript: space selects a line, enter edits it. Deleting and retranscribing ask first.
- AI notes, rendered as Markdown and streaming in while they are written.
- Chat.
The live screen shows the transcript as it arrives with your notes below it. Settings are the same forms as in the app, with masked entry for secrets and progress bars for model downloads. The keyboard tab lists every command with its current binding and where it came from, and enter records a new one.
The last row of every screen is a command line. Type / for every command, with its title, binding and a marker if it needs the Mac app. Missing arguments are prompted one at a time, and anything destructive asks inline. A listenr verb typed there, such as /record stop, runs as a subprocess, so searching the library and starting a recording use the same words as a script.
y copies the AI notes and Y the transcript through the Mac’s pasteboard. Over SSH that pasteboard is not the one you paste from, so the terminal also emits OSC 52, an escape sequence your terminal turns into a clipboard write. The text lands on the machine you are using (tmux needs set-clipboard on).
When the app is not running
The header says connected to the app or local (the app is not running). In local mode you can read the library, change settings and keys, and run any command that only touches files. Anything that needs the app, such as recording, says so and offers l to launch it.
Verb lines use the same exit codes a shell script branches on: a confirmation is shown and the line re-run with --yes if you accept, a step that has to finish in the app offers to open it, and a refusal shows its reason.
Keys in a terminal
- There is no Command key. A terminal never receives it, so terminal shortcuts use
ctrl,altandshift. - Some keys belong to the terminal.
ctrl+c,ctrl+zandctrl+\cannot be bound.ctrl+cpressed twice within a second force-quits. - A text field takes the keyboard. While you edit, bare keys type and the readline keys belong to the editor.
Terminal bindings live in the same config file the Mac app reads, under a tui surface. Leave the surface out and a binding applies to both, and null unbinds a default. The terminal re-reads the file when it changes, so a key bound from another shell works immediately.
{
"keybindings": [
{ "context": "global", "surface": "tui",
"bindings": { "ctrl+g": "meeting:regenerateNotes", "shift+s": null } }
]
}
What it will not do
- No audio playback. The player opens in the Mac app.
- No GUI flows. Sign-in, checkout, Google Calendar and Notion consent, macOS permission prompts and onboarding are handed off to the app rather than imitated in a terminal.
- Quitting never stops a recording. The recording belongs to the app, and the exit line says how to stop it.
The same actions everywhere
Every action in the Mac app is here under the same name with the same arguments. Destructive actions ask the same question, and anything the app would refuse right now is refused here for the same reason. The command line and the local MCP server reach the same actions, on every plan.