Overview
Patchlight in your terminal — scan the code on your disk right now, uncommitted work included, and triage the findings without leaving the shell.
@patchlight/cli is Patchlight for a developer at a terminal. It scans the working tree in front
of you — including the changes you have not committed — streams findings in as the model finishes
them, and drops you straight into triage when the scan ends.
npm install -g @patchlight/cli
patchlight login
cd your-repo && patchlight scan --diffNode.js 18.17+. That is the whole setup.
Sign in once
patchlight loginOpens a browser, shows a short code to confirm, and stores a token in
~/.patchlight/credentials.json with mode 0600. No secret ever passes through your shell
history, and the machine shows up in the dashboard under API Keys, where you can revoke it.
On a headless box or over SSH the code and URL are always printed too — open them wherever you are already signed in.
PATCHLIGHT_API_KEY wins whenever it is set. A CI job running on a machine somebody once logged
into still uses the credential its pipeline configured.
The one command to learn
patchlight scan --diff--diff reads only what this branch changed, plus same-directory siblings so cross-file flows stay
visible. Seconds, and cents. It is the one to run before every push.
A full-repository scan is a monthly thing:
patchlight scan # asks what to scan
patchlight scan --path src/apiRun patchlight scan with no flags and it asks first — changed files, whole repository, or one
directory — and tells you the flag that skips the question next time.
See Scanning for what each mode reads and how triage works.
Which package do I install?
@patchlight/cli and @patchlight/sdk are the same product with different jobs.
@patchlight/sdk | @patchlight/cli | |
|---|---|---|
| Built for | CI pipelines | developers at a terminal |
| Runtime dependencies | zero | ink, react, highlight.js |
| Authentication | PATCHLIGHT_API_KEY | patchlight login (browser) |
| Output | plain text, or --json | live TUI, then keyboard triage |
| Scans | a connected GitHub repo, server-side | the files on your disk |
Everything non-interactive — review, status, findings, repos, balance, --fail-on —
behaves identically in both, because the CLI delegates those commands to the SDK's own
implementation rather than reimplementing them. Installing the CLI does not change what your
pipeline does.
The split is deliberate: the SDK has zero runtime dependencies and stays that way so CI installs stay small and fast; a terminal UI needs a rendering layer that would destroy that. CI installs the small thing, developers install this one.
Both packages ship the same patchlight binary name. Install only one globally, or the later
install shadows the earlier one.