Dayflow: a local-first automatic work journal for Mac

The problem Dayflow solves, and for whom

App-level time trackers answer the wrong question. Knowing that Cursor was frontmost for two hours does not tell you whether that time went into shipping a feature, debugging auth, or reading documentation. Dayflow's premise is that the screen itself carries the context, so it captures lightweight screen chunks, analyzes them, and emits activity cards that describe the work rather than the window title. The README makes this argument directly: "Cursor for two hours could mean shipping a feature, debugging auth, reviewing a PR, or getting lost in setup."

The audience is narrow and specific. You need a Mac running macOS 14 or later, because the app depends on Screen & System Audio Recording permission, which is a macOS mechanism. The repository is Swift, the install path is a DMG or a Homebrew cask, and there is no server component to deploy. Anyone on Windows or Linux is out of scope, and the README does not suggest a port is planned. The second audience is people who already accept that a tool will look at their screen but want the analysis to stay on the machine, which is why local models through Ollama or LM Studio are a first-class option rather than an afterthought.

How the capture, analysis and timeline pipeline fits together

The mechanism has three stages, and the boundary between them is where the privacy story lives. First, Dayflow captures screen chunks while it runs. Second, it sends those chunks to an AI provider for analysis. Third, it stores the resulting activity cards and builds the timeline, standup view, weekly review, and chat answers on top of them.

The provider is a configuration choice, not a fixed dependency. The README lists local models through Ollama or LM Studio, Gemini with your own API key, and ChatGPT or Claude through their local CLI tools. That last option is worth reading carefully: the CLI tools run locally, but the model behind them does not, so routing through Codex CLI or Claude Code still means activity data leaves the machine. The README states the trade-off plainly: if you choose a cloud provider, activity data needed for analysis is sent to that provider; if you choose local models, analysis stays on your machine.

Storage is local by default. Recordings, timeline data, and the app database live under ~/Library/Application Support/Dayflow/. The README also describes configurable storage limits and automatic purging of old recordings, which matters because continuous screen capture grows without a ceiling otherwise. Above the timeline sit the derived views: a GitHub-style daily activity grid with yesterday's highlights, today's tasks and blockers; a weekly aggregation of focus patterns, categories, app usage and interaction graphs; distraction sessions shown next to focused work; and Markdown export for any date range.

Installing Dayflow on macOS and getting a first timeline

The README gives two install paths. The DMG route is manual: download the latest Dayflow.dmg from GitHub Releases, open it, drag Dayflow into Applications, then grant macOS Screen & System Audio Recording permission when prompted. The Homebrew route is one command:

brew install --cask dayflow

After that, launch the app and grant the same Screen & System Audio Recording permission. Nothing appears in the timeline until that permission is granted, because capture is the input to every downstream feature.

If you want the analysis to stay on the machine, install a local runtime first and point Dayflow at it. The README names Ollama and LM Studio as the two supported local options, and the requirements section lists an optional Gemini API key, Ollama, LM Studio, Codex CLI, or Claude Code depending on your preferred provider. There is no documented config file in the README for selecting the provider; the choice is presented as an in-app setting, so treat the provider selection as something you confirm in the app rather than in a dotfile.

To build from source instead of installing the release:

git clone https://github.com/JerryZLiu/Dayflow.git
cd Dayflow
open Dayflow/Dayflow.xcodeproj

Then select the Dayflow scheme in Xcode and run it. The repository layout matches that instruction: a Dayflow/ directory holding the Xcode project, a DayflowTests/ directory, plus docs/, scripts/ and tools/ at the top level. After a session of work, the expected result is a populated timeline of activity cards, and a Markdown export available for whatever date range you select.

Where Dayflow stops being the right tool

The hardest constraint is the platform. macOS 14 or later, no exception in the README, and a permission that many corporate device-management profiles restrict or block outright. If you cannot grant Screen & System Audio Recording, the app has no input and therefore no output. That is not a bug to work around; it is the architecture.

The second limitation is fidelity. Dayflow is a journal, not an invoice. It reconstructs what you did from sampled screen chunks, so it is suited to standups, weekly reviews, client notes and personal retrospectives. If you need defensible hours for billing, or a tracker that runs on a phone and a Windows laptop alongside your Mac, this is the wrong category of tool. The README never claims billing-grade accuracy, and it should not be read that way.

The third is the dependency on an external model for the interesting part. Capture and storage are local, but the summaries, the chat answers, and the standup extraction all depend on a provider. With local models you pay in speed and summary quality; with cloud providers you pay in data leaving the machine. There is no third mode in the README where Dayflow does its own summarization without a model. The README also does not document rollback, migration, or what happens to existing timeline data when you switch providers mid-week, so treat a provider change as an experiment on data you can afford to lose.

Dayflow compared with calendar-first and timer-first tools

The obvious alternative is a manual timer: Toggl, Clockify, or a spreadsheet with start and stop buttons. The difference is the input. A timer records what you remembered to start, which means meetings, interruptions and context switches vanish, and the day's total depends on your discipline. Dayflow records what was on screen, so the record exists whether or not you pressed anything. The cost is the permission and the capture itself.

A second alternative is a calendar or planner, which is the shape most people mean when they search for a daily scheduling app. A calendar stores intentions: what you planned to do at 10am. Dayflow stores evidence: what was actually on screen at 10am. The README's weekly review and standup views are attempts to reconcile the two, but Dayflow is not a scheduler and does not claim to be one. If your problem is deciding what to work on next, a planner is the right tool. If your problem is reconstructing what already happened, Dayflow is aimed at that.

A third comparison is with cloud screen-recording or employee-monitoring products. The difference is not the capture, which is similar, but the destination. Dayflow is MIT licensed and local-first, and the README states that recordings, timeline data and the app database stay on your Mac by default and can be deleted whenever you want. That is a materially different posture from a tool whose data lands in a vendor dashboard. It is also why the provider choice matters so much: the local-first claim is about storage, and the README is explicit that analysis can still leave the machine.

Maintenance, upgrades and what the MIT licence covers

The repository is not archived, and the last push was on 2026-09-09. The release history in that window is dense: v2.2.0 on 2026-09-03, v2.4.0 on 2026-09-07, and v2.4.2 on 2026-09-09. That cadence suggests active work on the app, and it also means you should expect to update rather than install once. The Homebrew cask path makes that cheap: brew upgrade --cask dayflow picks up a new DMG without a manual download. If you build from source, you are tracking main and owning the Xcode build yourself.

The upgrade cost that matters is not the binary, it is the data. Dayflow writes recordings, timeline data and a database under ~/Library/Application Support/Dayflow/, and it offers configurable storage limits with automatic purging of old recordings. A version bump that changes the database schema is the scenario to think about before you have six months of history you care about. The README does not document a backup command, an export-before-upgrade step, or a schema migration policy. The Markdown timeline export is the closest thing to an escape hatch, and it is worth using it periodically for any range you would be annoyed to lose.

The licence is MIT. That permits commercial use, modification and redistribution, and it comes with no warranty, which is the standard MIT position. It says nothing about the data you capture, and it does not change the fact that if you point Dayflow at a cloud provider, that provider's terms govern what happens to the activity data sent for analysis. If you are deploying this on a managed work laptop, the permission prompt and the provider choice are the two decisions that belong to whoever owns that machine's policy, not to the app.

Editorial conclusion

Adopt Dayflow if you work on macOS 14 or later, want a timeline you did not have to start manually, and are willing to grant Screen & System Audio Recording permission. Do not adopt it if you need Windows or Linux, if you cannot accept periodic screen capture on a work machine, or if you need a time tracker that produces billable hours to the minute. Before trusting it, verify three things yourself: which AI provider you will point it at and whether that provider sees your screen data, where the database and recordings sit under ~/Library/Application Support/Dayflow/, and how the storage limit and automatic cleanup behave once your first week of recordings accumulates.

Frequently asked questions

Official sources

1. JerryZLiu/Dayflow on GitHub
2. License: MIT
3. Project website
4. README
5. Releases