A tiny, no-nonsense macOS menu bar timer for Clockify.
One button. One running entry. No permissions, no Electron, no Xcode.
The official Clockify desktop app does a lot. It also asks for Accessibility and Screen Recording permissions to detect idle time and screen lock, gets confused about which timer is running, and is more app than a "start timer, stop timer" workflow needs.
Clockify Timer does exactly one thing: it tracks the time you spend at your Mac into a single Clockify project, and it does it reliably. Everything else (reports, history, projects, tasks, tags, team features) lives in the Clockify web app, where it belongs.
- Screen lock automation – optionally stop the timer when the screen locks and start it again on unlock. The auto-start only happens if the lock stopped the timer; if you stopped it yourself, unlocking does nothing.
- Survives restarts – a running timer is remembered locally, so the menu bar keeps counting after a relaunch and Stop still closes the right Clockify entry.
- Launch at login – one toggle, using the system login item API.
- Keychain – the API key is stored in the macOS Keychain, never in a plist.
- Logging – a daily log (today and yesterday are kept) with every API call, lock/unlock, idle event and your Work/Pause choices. Settings › Diagnostics copies it to the clipboard for bug reports. The API key is never logged.
| Clockify Timer | Official Clockify Desktop | |
|---|---|---|
| Idle / lock detection | Works out of the box via public system APIs | Requires adding the app under Privacy & Security › Accessibility |
| "Was that a pause?" prompt | Asks on return, splits the entry at the exact moment you left | Similar, but depends on the permission above |
| Timer state | One entry, one source of truth, restored after restart | Its own settings warn that desktop and web timer can get out of sync |
| Scope | Start, stop, idle handling. Nothing else. | Full client: projects, tasks, tags, history, reports |
| Menu bar | Colored pill + fixed-width time, always visible | Icon only |
| Diagnostics | Plain-text log you can read and paste | — |
There is no project picker, no task list, no description editor, no history and no reports. Every entry goes to one project that you configure once. That is on purpose:
- Most people who want a timer in the menu bar track "I am working" and sort out the details in the web app later, if at all.
- Fewer features means fewer states, which means fewer ways for the timer to be wrong.
- The Clockify web app already does everything else well.
If you need several projects, switch the project ID in Settings. The running entry keeps its project; the next one uses the new ID.
Requires macOS 14 or newer and the Xcode Command Line Tools (xcode-select --install). A full Xcode installation is not needed.
git clone git@github.com:ReuDa/clockify-simple-client.git
cd clockify-simple-client
./build.sh # builds with SwiftPM and creates dist/Clockify Timer.app
open "dist/Clockify Timer.app"Then click the red pill in the menu bar › Settings and enter:
| Field | Where to find it |
|---|---|
| Workspace ID | Clockify web app › open any project; the URL looks like app.clockify.me/projects/<projectId>/... and the workspace ID is shown under Workspace settings, or via GET https://api.clockify.me/api/v1/workspaces |
| Project ID | Same URL as above |
| API Key | Clockify web app › Preferences › Advanced › API |
Settings take effect immediately, no restart needed.
cp -R "dist/Clockify Timer.app" /Applications/
open "/Applications/Clockify Timer.app"Turn on Launch at login in Settings once the app runs from /Applications. Your settings, the Keychain entry and a running timer are stored per user, not inside the bundle, so they survive reinstalling the app.
git pull
./build.sh
pkill -x ClockifyMenuBar # or Quit from the popover
rm -rf "/Applications/Clockify Timer.app" && cp -R "dist/Clockify Timer.app" /Applications/
open "/Applications/Clockify Timer.app"A timer that was running before the update continues afterwards.
build.sh signs the app ad-hoc. Every ad-hoc build has a new identity, so after each rebuild macOS asks once whether the new build may read the API key from the Keychain. Click Always Allow.
To get rid of the prompt, create a self-signed code-signing certificate in Keychain Access (Certificate Assistant › Create a Certificate…, type Code Signing) and build with a stable identity:
CODESIGN_IDENTITY="Clockify Timer Dev" ./build.shOnly two endpoints of the Clockify REST API are used:
POST /workspaces/{workspaceId}/time-entries– on Start, withstartandprojectIdPUT /workspaces/{workspaceId}/time-entries/{id}– on Stop (or Pause), withstart,endandprojectId
Sources/ClockifyMenuBar/
ClockifyMenuBarApp.swift app entry, MenuBarExtra + Settings scene
ClockifyClient.swift the two API calls
TimerModel.swift timer state, persistence, start/stop/split
IdleMonitor.swift idle, lock, sleep detection and lock automation
AwayPromptWindow.swift the "Work or Pause?" panel
MenuBarIcon.swift draws the menu bar pill and time
SettingsView.swift settings form
Keychain.swift API key storage
LoginItem.swift launch at login
Log.swift daily file logger
Resources/Info.plist bundle metadata (LSUIElement hides the Dock icon)
build.sh SwiftPM build + .app bundling + signing
- Nothing happens on Start – open Settings and check that all three fields are filled; the popover shows the API error, e.g.
HTTP 404usually means a wrong workspace or project ID. - Timer stuck – the popover offers Discard running timer locally if Clockify and the app disagree.
- Anything else – Settings › Diagnostics › Copy log to clipboard and open an issue with the log.



