Workrail
⌘K
CLI

How CLI Sync Works

Learn what data sync uses, how entries are grouped, and what affects output quality.

Updated 2026-02-24

This guide explains what happens when you run workrail sync.

What sync reads

Workrail reads git metadata from your local repository, including:

  • commit hash and timestamp
  • commit message text
  • branch/ref text
  • changed file paths
  • aggregate change counts

It does not read or upload source code content.

What sync sends

The CLI sends metadata to Workrail so entries can be grouped and summarized.

How entries are created

Workrail groups related commits into higher-signal entries by looking for:

  • shared files or areas
  • similar commit intent
  • timing proximity
  • repeated themes across commits

CLI-generated entry dates are attributed from commit timing in your local timezone (not the ingestion timestamp), including a small cross-midnight grace window to keep contiguous late-night work together.

What affects quality

Higher-quality sync output usually comes from:

  • clear commit messages
  • consistent naming for features/areas
  • regular sync cadence
  • Run workrail sync after a coding block
  • Trial: use workrail sync for forward-only sync
  • Pro: use workrail sync --since 7d only for intentional backfill (max 30 days)
  • Use workrail sync --catchup for resumable backlog recovery (default 14 days)
  • Use workrail sync --catchup --catchup-days 4 when you want a smaller targeted catchup window
  • Use --max-runtime-minutes if you want predictable bounded runs
  • Enable autosync on your main machine if preferred