What DevClocked Collects — And What It Never Touches
The exact data each DevClocked tracker transmits, the keystroke, screenshot, clipboard, prompt, and code content none of them can read, and how team visibility and retention are enforced.
Two questions decide whether a tracker is safe to bring to work: "can my boss spy on me with this?" and "can managers rank engineers with it?". DevClocked is built so the answer to both is no, and this page shows the mechanism instead of asking you to trust a policy. Below is what leaves your machine, what never does, who can see which parts, and why a ranking can't fall out of the data. Every claim here was checked against tracker source code before publication.
Never collected
- Keystrokes — the desktop app's only input-related API call asks macOS one question: how many seconds since the last keyboard or mouse event (
CGEventSourceSecondsSinceLastEventType). One number, used to detect idle. No event tap, no key monitor, no keylogging API is compiled into the binary. Thedevclockedterminal wrapper passes your typing straight through to your shell and transmits only repo, branch, and a timestamp. - Screenshots — no screen-capture API is linked in any tracker.
- Clipboard — no clipboard or pasteboard API, in any tracker.
- Your code — commit and edit parsing reduces to integers.
git diff HEAD --numstatruns locally and only the added and removed line counts leave; AI edit contents are replaced with blank placeholder lines before they even reach the local queue file. Diff hunks, file contents, and commit messages are never transmitted. - Prompts and AI transcripts — the daemon reads agent session logs through a whitelist-only scrubber: 19 named fields for Claude Code, 16 for Codex CLI (timestamps, model names, token counts, line counts, tool names). A field not on the list cannot pass, because no code path reads it. Raw session files are scrubbed in memory and never stored or transmitted. One further opt-in is described below.
- Terminal output — command output is pattern-matched locally into a single "did this look like an error" boolean, and even that boolean stays on your machine. It only informs the activity label (debugging, for example), which is what actually leaves.
- Browsing outside development — the browser extension checks every domain against a fixed allowlist of developer domains (91 entries at the time of writing, subdomains included) before a tick is even constructed. Everything else is invisible to it. It has no content scripts, so it cannot read the contents of any page, and it transmits no page titles. Query strings and fragments are stripped from tracked URLs before sending.
- Sensitive filenames, in the daemon — the daemon's path filter drops
.env*,credentials.*,.pem,.key,.p12,.pfx,.jks,id_rsa,id_ed25519, and.secretfiles, and strips your home directory from every path it does send. The editor extension is looser about paths; the next section says exactly how.
What is collected
Time tracking needs data, and pretending otherwise would make everything above less believable. This is the full list, sharp edges included.
| Data | What leaves your machine |
|---|---|
| Time and presence | Tick timestamps, session start and end, idle state, the device name you set, and the name of the frontmost development tool (Zed or Warp, for example) while you are active. |
| Where you work | Project, repository (owner/name), and branch names. The daemon and IDE plugins also send your workspace folder path in plain text — an absolute path, so it can include your macOS username. |
| Files you edit | The VS Code / Cursor extension and the Cursor plugin transmit the full path of the file you are editing (node_modules, .git, dist, and build excluded — the sensitive-filename filter above does not apply here). The daemon sends home-stripped, filtered paths for Codex CLI and no file paths at all for Claude Code sessions. File contents never leave in either case. |
| Output counts | Lines added and removed, files-changed counts, language or file extension, and commit SHAs with timestamps. No contents, no commit messages. |
| AI usage | Tool and model names, token counts, agent runtime and turn counts, tool-call names (Edit, Bash, Read), and a derived activity label such as building or debugging. |
| Dev-domain URLs | Origin plus path of pages on allowlisted domains. Paths can name things: github.com/acme/secret-project/pull/12 identifies a private repo to your own dashboard. The allowlist also includes AI chat (claude.ai, chatgpt.com) and meeting domains (zoom.us, meet.google.com), so time there counts as tracked activity. |
All of it lands in your own account and your own dashboards. What a teammate or manager can see is a far smaller, pre-redacted subset — covered two sections down.
Optional, off by default
- Figma window titles — file-level design tracking reads the focused window title of the Figma desktop app, and only Figma, through the macOS Accessibility permission; that title read is the only thing the permission is used for. The raw title is transmitted along with a parsed file and project hint. The toggle ships off; without it, Figma tracking records app presence only.
- Session titles — the "Sync session names" opt-in sends the AI-generated title of a coding session ("Implement CI merge gates"), a model-written summary derived from your prompt. It is off by default; turn it on in DevClocked for Mac → Settings → Privacy. Your raw prompt text is never read under any setting.
Not an employee ranking
Leverage measures a workflow, not a person. It is the ratio of output-unlocked time to hands-on attention, on the same 1–10 scale for everyone, and it always decomposes into its inputs (attention hours, agent runtime, output signals) rather than standing alone as a verdict. Velocity scoring of hands-on building is normalised against your own trailing 14-day baseline, not a company norm.
The ranking guarantee itself is structural. Team surfaces contain no ranked list of people. Per-member figures appear only at the sharing level that member chose. And the only leaderboard in the product is the public one you opt into from your own profile. The full stance, including the uses team metrics must never be put to, is in measurement ethics.
Who sees what on a team
You always see your own everything. Teammates and managers see only rows from pre-redacted daily rollup tables (shared_project_member_daily and its issue-tracker sibling) that a server-side job builds at each member's sharing level. Those tables have no URL, file path, commit message, prompt, or session-detail columns, so a team query cannot return what was never written into it.
Sharing has four levels: private, totals, summary, enhanced. Private is where every workspace member starts, and it generates nothing — the rollup job deletes any existing rows for a private member before it aggregates, and a database constraint makes a private rollup row impossible to store. Lowering your level re-redacts immediately, not at the next sync.
Retention
Raw activity is kept for your plan's retention window (7 days on Free, 365 on Pro, unlimited on Ultra and Team, as of publication) plus a 7-day grace buffer. A database job runs daily and deletes raw activity ticks, agent turn events, and expired sessions past that window. Deliberately kept: git history (commits and pull requests, which re-sync from GitHub anyway), invoicing records, and the derived daily and hourly aggregates that power long-term charts.
For how each metric is computed, see How DevClocked Measures. For what team metrics are for and what they must never become, see Measurement Ethics. The legal privacy policy lives at /privacy.
Was this page helpful?