VS Code Time Tracking: How to Track Coding Time in VS Code (2026)

What VS Code time tracking can and cannot see

Before you install anything, it helps to be precise about what a tool bolted into your editor is watching, because that boundary decides how accurate your number will be. A VS Code time tracker observes the editor window: which file is focused, when you are typing, and sometimes which language and project you are in. That is genuinely useful, and it is passive, which already beats a manual timer you forget to start.

The boundary is the editor frame itself. Most developers hit this the first time they check a plugin's dashboard after a heavy day and the total looks low. The reason is that modern work leaks out of the editor constantly. You run builds and tests in an integrated terminal, you drive an agent from the command line, you read docs in the browser, and you switch to another tool for a specific task. A VS Code extension counts none of that as coding time, because from its point of view nothing is happening in the editor. Editor-based tracking measures editor activity, which is a subset of your real work, and the subset is shrinking as more of the job moves to the terminal and to agents.

The three ways to track time in VS Code

There are really three routes, and they differ in what they can see and how much you have to trust them. Here they are side by side before we go deep on each, so the trade-offs are visible up front.

The shape of that table is the lesson. The method that installs cleanly into VS Code sees the least of your day, and the method that sees the whole day needs a tracker that is not tied to the editor at all. There is no option that reads your true hours from nothing. Below, each route in turn.

Route 1: a VS Code extension (the fast path)

Most people start here, and it is a reasonable place to start. You install an extension like WakaTime from the marketplace, paste an API key, and from then on it records your editing passively. If you have ever wanted to know which languages ate your week or how long a project has had you in the editor, this is where those charts come from, with no behaviour change on your part.

The limitation is coverage, and it matters more every year. The extension sees VS Code and only VS Code, so a terminal-heavy or agent-heavy day reads as light editing. It also does not travel: if you open a project in a JetBrains IDE or drive a task from the command line, that time is invisible unless you install and configure the same tooling in every place you work. This is exactly why the "no plugin" search intent exists, and it is worth being precise about the phrase. A coding time tracker without an IDE plugin means one editor-agnostic tracker instead of one plugin per editor, or a git baseline that needs nothing installed, rather than no software at all. If you are weighing the plugin category itself, the best WakaTime alternatives lay out the options, and the DevClocked vs WakaTime comparison covers where an editor plugin stops being enough. There is also a WakaTime alternative page if you have already decided to switch.

Route 2: git-based inference (zero setup)

If installing an extension feels like too much, the appealing idea is to skip the editor entirely and read your time from git, since the commits are already sitting in the repo. You can get a real baseline this way. A good git-based estimate does not count commits, because a commit can represent five seconds or five hours. It reconstructs sessions by grouping commits that sit close together in time and treating long quiet gaps as breaks, then estimates elapsed time from the shape of that activity.

Most "track time from git" advice skips the limitation that applies to VS Code work as much as anywhere: git records output, not effort, and in 2026 those two have come apart. An agent generates a huge diff in seconds, so a large commit can represent almost no time, while a one-line fix can follow an hour of debugging inside your editor. The thing git can see, the size and timing of the diff, no longer maps cleanly to the thing you want, which is time spent. Treat git as a strong benchmark and a cross-check, never as an accurate clock. Tracking coding time from git goes deeper on getting the most out of the baseline without over-trusting it.

Route 3: telemetry from an editor-agnostic tracker (the accurate path)

If a plugin measures the editor and git infers time after the fact from output, telemetry measures the work while it happens across your whole environment, which is the only way to get an honest number. Telemetry here means lightweight activity signals captured as you work: active editing in VS Code, yes, but also terminal sessions and agentic coding sessions. Because it observes the work directly rather than the editor window alone, it catches the hour you spent in the integrated terminal and the agent run that produced a giant commit in two minutes, precisely the cases where an editor plugin and a git estimate both get it wrong.

This is what makes a VS Code time total trustworthy. In a world where code is cheap to generate and much of the work happens next to the editor rather than inside it, watching the real activity is the only reliable measure. The cost is that telemetry needs a small tracker running, either a lightweight editor extension or an editor-agnostic CLI that also covers terminal and agent work. That is the trade across the whole table: a little software watching, in exchange for hours you do not have to reconstruct or defend from memory. If you also work in a VS Code fork, the same logic and setup carry over, which is what tracking Cursor usage walks through.

How to pick a route for your situation

The right choice is rarely one route, it is usually a small stack, and it depends on why you are tracking at all. Most VS Code developers land in one of a few situations, so match yourself to the closest.

If you want a sense of your editing habits with the least effort, a plugin is fine, as long as you remember it is undercounting your terminal and agent time. If you bill clients, a plugin alone is risky, because the hours it misses are hours you either lose or have to reconstruct, so you want passive capture that covers the whole environment plus a record you can show. If you build heavily with AI inside VS Code, an editor-only plugin will undercount you badly, because so much happens in the terminal and in agent sessions the plugin never sees, and git will misread the diffs, so telemetry is doing the real work. And if you want a rough number with zero setup, the git baseline is a reasonable starting point as long as you treat it as approximate and expect it to drift the more you lean on AI. The pattern across all of these: the more your hours need to survive someone else's scrutiny, the more you want measured activity rather than a partial or self-reported figure.

Common mistakes

A few errors show up constantly with VS Code tracking, and they are easy to avoid once named. The most common is assuming the plugin's total is your real coding time, when it is only your in-editor time, so a terminal-heavy day looks lazy on the chart. The second is installing a tracker in VS Code and nowhere else, then wondering why the numbers drop whenever you work in another tool. The third is trusting commit volume as a proxy for effort, which was shaky before AI and is now wrong. The fourth, and the one that quietly matters most, is treating any of these numbers as proof when they are really claims. A plugin heatmap or a padded commit graph proves nothing to a client or an employer on its own. The fix in every case is the same move: measure the work as it happens across the whole environment, and keep the record, rather than reconstruct a partial view later and ask people to take your word.

Where DevClocked fits

Full disclosure: I build DevClocked, so treat this as the honest placement, not a verdict. DevClocked leads with leverage and output, measuring what you and your AI coding agents shipped, not just keystrokes in one editor. The mechanism is the combination this guide keeps pointing at: a git baseline that needs no per-editor plugin, plus telemetry from a lightweight extension and an editor-agnostic CLI that covers the terminal and agent sessions VS Code plugins miss, with a model that learns the relationship between your commits and your measured activity so the estimate calibrates over time.

Be honest about when it is not the answer. If all you want is a per-language heatmap of your editing and you never leave VS Code, a plain editor plugin is less to think about and does that job well. If you want your entire non-coding workday tracked, a general tracker like RescueTime fits better, and WakaTime vs RescueTime covers that split. If you refuse to install any tracker at all, you are left with the git baseline alone, and you should treat it as approximate. DevClocked earns its place when your work is code, a real share of it happens in the terminal and in agents rather than the editor, and you want an accurate measure that doubles as a record you can stand behind. A developer dashboard is where those hours turn into something you can read and show.

Related Guides

• Developer time tracking: the complete guide: the four methods to track coding time and how to pick, in depth.
• Coding time tracker without an IDE plugin: what "no plugin" really means and the editor-agnostic option.
• Track Cursor usage: the same setup for the VS Code fork, including agent sessions.
• Track coding time from git: how the git baseline works and why it is a benchmark, not a clock.
• Best WakaTime alternatives: the ranked comparison if the plugin route is not covering your work.
• Developer dashboard: turning tracked hours into something you can read and show.