Time tracking for developers, beyond the editor
Editor plugins in this category mainly take a heartbeat from the editor, for the file and project you are in. What they record is the stretch spent writing code. WakaTime’s editor plugins are one example; this describes the scope when you have only an editor plugin installed. The same day also includes reading docs, reading issues on GitHub, running builds in the terminal, and going back and forth with Claude Code or Codex to change an implementation. The editor is often not in front then, so the plugin record leaves a gap. Hina records apps across the Mac, time spent, and input counts, then assigns segments that match a repository to a project. Those stretches outside the editor do not vanish entirely.
Stretches a plugin cannot record
When you read docs or an issue, the frontmost app has usually switched to Safari or Chrome. The page may be a README in the repository, an API doc, or an issue you just opened on GitHub. An editor plugin cannot reach that window, so no project heartbeat is recorded there. Hina records the browser as an app and the time spent. You can at least see that a long stretch of the morning was in the browser, not the editor.
Terminal time is another stretch. You run builds, look through logs, and check git status in Terminal or iTerm. The cursor is not in the editor, so the plugin heartbeat stops as well. Hina records how long the terminal app stayed in front. Commands you type are not read by default. Terminal history needs a separate permission and is off by default. After you turn it on, it is read only when a daily report is made, and the report keeps only the command and subcommand, such as npm run or brew install, plus the file name when you run your own script. Commands like cd, ls, and git status do not enter the report at all. Other paths and the options after them are not kept.
Time with Claude Code or Codex is easy to miss as well. The conversation occupies the terminal while you look at which files it changed in the blog repository and whether to accept this step. Your hands rarely go back to the editor to type, so the plugin records almost nothing. You are working, but the heartbeat is not in the editor.
Assigning a repo from window titles and session directories
Editor plugins usually decide the project from the file you are editing. Close that file, or switch to the browser, and the record on the project side stops. Hina does not read the plugin heartbeat. To recognize a project, it looks for a repository path in the terminal or editor window title. Titles in VS Code, Cursor, or Terminal often include the repository name. Window titles have to be turned on with Record window titles and page paths on the Privacy tab of Settings. If they are off, only the app name and time spent remain. Once they are on, foreground time is assigned to the blog repository when the title shows that repository’s path. If the title has no repository path, the time stays on the app and is not forced into a project.
Claude Code and Codex sessions are also used to assign a project, once Read agent sessions is turned on on the Privacy tab of Settings, which is off by default. They have a working directory when they start, and a start time and an end time. Hina matches the directory to repositories on your machine. If the whole stretch is spent in the terminal revising the client site repository with Claude Code or Codex, and the editor was never opened, that project is not missing the stretch. A session’s working directory and git commits are separate. Commits show which changes were left in the repository. The working directory explains which project you were in during that time. The two being close in time does not mean that question was already finished.
Two boundaries that are easy to misread
When Hina compares a project with local git, it does not filter commits by author. A commit you wrote, and one a colleague wrote in the same blog repository, are not dropped because the author is different. This is not a contribution report split by person. The number of commits cannot be converted into time spent in front of this Mac. To see what was left in the code today, open that repository and look at the diff. The Trail tells you that the foreground at the time was assigned to this project.
A split terminal has another limit. With Terminal or iTerm divided into a left pane and a right pane, tests for the blog repository running on the left and the client site repository on the right, Hina only sees the pane that has focus. The unfocused pane’s directory, and what it is running, are not in the record. If you remember a long task open on the right but the project on the daily report does not match, you can start by checking which pane had focus at the time.