Worklog

An always-on macOS menu-bar recorder for people whose best conversations happen away from the keyboard.
Record all day · clip the moment that mattered · read it back, on-device or diarized in the cloud.

---

Why

Someone walks up to your desk, you talk through a task for fifteen minutes, they leave - and the details live only in your memory. Worklog exists so that conversation is always already recorded. When it ends, you open the app, grab the last N minutes, trim to the part that mattered by eye and ear, and hit Create. A minute later you have a speaker-labelled transcript (plus translations and a summary, if you want them) ready to paste anywhere.

It was built to fix the two ways general-purpose recorders quietly betray you:

• They stop when Bluetooth devices connect or disconnect. Worklog pins capture to one input device by its hardware UID and never follows the system default. Other devices coming and going don't touch it.
• They record from the headset mic. Worklog records from the device you chose, always - never whatever just connected.

If the pinned device genuinely disappears, Worklog shows a loud warning state and notifies you - it never switches mics silently and never stops silently. It survives sleep/wake, rolls across midnight, auto-restarts its engine on capture errors, and if it was recording when the machine crashed or rebooted, it resumes on the next launch and tells you it did.

Features

• Always-on recording - rolling 5-minute mono AAC segments (~28 MB/hour), organized by date, crash-safe by construction. Configurable retention (7/14/30 days, 1 year, never) purges only raw audio; clips and transcripts are never auto-deleted.
• Clip screen - load the last 5/15/30/N minutes or any historical date-time range (segments stitch into one seamless waveform), scrub, play, and drag start/end handles. Silence→speech transitions are detected, ranked, and offered as numbered, auditionable start-point suggestions - you always make the final call.
• Live waveform - a range that includes "now" keeps growing while you watch, fed by in-memory peaks straight from the audio tap. Amplitude auto-scales to the loudest peak in view.
• On-device transcription - speech recognised on this Mac itself, with no account, no network and no cost. Runs alongside recording and, when you have not set up a cloud transcription key, becomes the transcript outright, always labelled with where it came from. Pick your languages in Settings and download more on demand. Off by default.
• Transcription pipeline - clip → diarized transcript (ElevenLabs Scribe v2) → translations into each enabled language, in parallel → optional summary built from the raw transcript or a translation of your choice (Anthropic-compatible LLM; base URL, model, and effort are configurable, so a LiteLLM-style proxy works too). Every step's state is persisted; any step can be retried alone - even after success - without re-running (or re-paying for) the others.
• Library - every clip with live per-step progress, a seekable player, collapsible sections per artifact with copy / reveal-in-Finder / retry, rename and delete via right-click, and reverse-geocoded location linked to Apple Maps.
• Search - fuzzy search across clip names, dates, transcripts, translations, and summaries, indexed incrementally in the background. ⌘F to focus.
• Your data stays on your disk - everything lives in ~/worklog as plain files plus one SQLite database you can open yourself. No app container, no sync, no telemetry. Recording, clipping, playback, and search work fully offline with no keys; audio leaves your machine only when you run a transcription, and only to the providers you configured.
• Menu-bar native - lives in the menu bar; gains a Dock icon and Cmd-Tab presence while its window is open. Launches at login. Location tagging (for "where was this recorded") is permission-gated and layered to survive relaunches.

Transcription, two ways

Worklog can read a recording back to you without anything leaving the Mac. On-device speech recognition runs alongside capture and produces timestamped words that drive the transcript view, the clip-range edges, and the live dictation bubble.

If you never configure a cloud key, that is your transcript. If you do, the accurate diarized version arrives too, and the on-device one stays beside it permanently - it is the only record of what this Mac itself heard, and it survives long after the raw audio ages out of retention.

Apple's on-device transcriber covers 30 locales, listed in Settings with a download button for the ones you do not have yet. Hindi is not among them today; that is a platform limit, and Worklog deliberately does not fall back to a cloud recognizer to paper over it. See docs/speech-previews.md.

Install

Grab the latest build from Releases (see "Opening it the first time" below), or build from source:

Build from source:

git clone https://github.com/rishabhrao/worklog-mac.git
cd worklog-mac
./build.sh release
open worklog.app

Requirements: macOS 14+ and Xcode (or Command Line Tools) for the Swift compiler and SDK. There are zero third-party dependencies - the package manifest pulls nothing; the app links only Apple system frameworks and the libsqlite3 that ships with macOS (via a small hand-rolled wrapper, no ORM).

The optional flake.nix/.envrc pin helper CLIs for development; they do not provide Swift. build.sh detects a Nix shell exporting Apple-SDK environment and re-points itself at the real Apple toolchain automatically.

Note on signing: build.sh ad-hoc signs by default. That works, but ad-hoc signatures are identified by a hash of the binary, so every rebuild produces a different identity, and macOS ties permission grants (Accessibility, needed for dictation) to that identity. The practical effect is that each rebuild silently breaks the dictation hotkey.

Signing with a stable self-signed certificate avoids all of it. Create one in Keychain Access → Certificate Assistant → Create a Certificate, any name, type Code Signing, self-signed - then either name it Worklog Local Dev or point build.sh at it:

WORKLOG_SIGN_IDENTITY="My Signing Cert" ./build.sh release

The certificate needs no trusted chain; it only has to stay the same between builds, which is what keeps the signature's designated requirement stable. build.sh uses the identity when it finds one and falls back to ad-hoc when it doesn't.

One thing a stable certificate does not fix: the Keychain "Worklog wants to access key" prompt after each rebuild. Permission grants key off the designated requirement, which stays stable, but the Keychain gates on the item's partition list, and without an Apple Team ID the only identity available there is the binary's cdhash, which changes every build. There is no free fix; see the note in Sources/Worklog/Storage/KeychainStore.swift.

Forks should change BUNDLE_ID in build.sh.

Opening it the first time

The released build is signed with a self-signed certificate, not an Apple Developer ID, because notarization requires a paid Apple account. macOS will therefore refuse to open it on the first try. This is the usual dance for independently distributed apps:

1. Unzip and drag Worklog.app to /Applications.
2. Double-click it. macOS says it "cannot be opened because Apple cannot check it for malicious software". Click Done.
3. Open System Settings → Privacy & Security, scroll to Security, and click Open Anyway next to the Worklog message.
4. Confirm. macOS remembers the decision; you only do this once.

If you would rather not, build from source above; the result is identical and signed by you.

First run

A short onboarding asks you to pick the input device to pin and grant microphone access - that's all recording needs. API keys are only required for the transcription pipeline and are entered in Settings, stored exclusively in the macOS Keychain:

• ElevenLabs - Scribe v2 diarized speech-to-text. An optional "disable logging" toggle opts requests out of ElevenLabs' logging (zero-retention mode; requires an enterprise key).
• Anthropic (or any Anthropic-compatible endpoint) - translations and summaries.

Recording never starts on its own; hit Start in the menu bar or the sidebar. The one exception: if the app was recording when it crashed or the machine rebooted, it resumes automatically and notifies you.

How your data is laid out

~/worklog/
├── recordings/                      # raw all-day audio - the only thing retention touches
│   └── 2026-07-10/
│       └── 0900_00.m4a              # rolling 5-minute segments
├── clips/
│   └── <clip-id>/                   # one folder per clip, every artifact together
│       ├── audio.m4a
│       ├── transcript.json          # diarized Scribe response, verbatim
│       ├── translation-<language>.md
│       └── summary.md
└── worklog.db                       # SQLite: segments, clips, transcripts, translations,
                                     # summaries, waveform peak caches, app settings

Everything is a plain file you can browse in Finder; sqlite3 ~/worklog/worklog.db works. API keys are never on disk.

Design notes

• The recording controller is the single source of truth for capture state; menu bar, sidebar, and notifications all read the same published state. Start/stop is modeled as commands from trigger sources (manual, crash recovery) so future auto-triggers don't require rewriting capture.
• The pipeline data model is a strict hierarchy - one transcript per clip, many translations per transcript, one summary per transcript (optionally derived from a translation). Providers, models, and languages are recorded as data on each row at run time, never encoded as code-level concepts: adding a language is a Settings change, not a schema change.
• Design system throughout - semantic color tokens, a spacing/typography scale, and shared motion primitives (spring-based, interruptible, Reduce Motion-aware) power every screen.

A note on recording consent

Worklog records continuously by design. You are responsible for complying with your local recording-consent laws - one-party vs. all-party consent rules vary by country and state.

License

MIT