Troubleshooting

Real failure modes, verified against the CLI's source, not a generic FAQ. If something here doesn't match what you're seeing, open an issue.

redential logindoesn't open a browser

Expected on a headless machine, over SSH, or if no browser/opener binary is available. Auto-opening the verification URL is a best-effort convenience, never load-bearing. Any failure to open it (unknown platform, no browser installed, the opener binary missing) is silently swallowed, and login proceeds exactly as if auto-open didn't exist.

Look for the printed verification_uri and code in your terminal output and open the URL yourself, then enter the code:

What login prints
First, go to: https://www.redential.com/cli/activate
Then enter this code: WDJB-MJHT
Waiting for confirmation...

Auto-open only ever tries http/https URLs, never a file://or custom scheme, and only via your OS's native opener (never a shell string). This failing safely-shut is expected behavior, not a bug to work around with elevated permissions or a different shell.

scansays "no commits yet" on a repo that clearly has history

scan reads your full history with a single git log --numstatcall, buffered entirely in memory. On a very large repository, long history, huge diffs, that output can exceed Node's default 1 MB buffer for the underlying process call. When that happens, the CLI currently treats it the same as "this repo has no commits" and you'll see:

Error
Error: This repository has no commits yet — nothing to scan.
If you know the repo has history, don't take this message at face value on an unusually large repo. It can mean the git output overflowed the buffer, not that there's genuinely nothing to scan. This is a known sharp edge, not a documented limit; if you hit it, it's worth filing an issue with the repo's approximate commit count and total diff size.

For most repositories this never comes up, it takes an unusually large history to hit the default buffer.

Hangs, or fails immediately, in CI

Every interactive prompt (the authorization attestation, author selection, and submit's upload confirmation) reads from stdin. In a CI job with no attached terminal, stdin is typically closed (EOF) from the start. The CLI treats EOF on any of these prompts as a hard failure (a non-zero exit) rather than hanging forever or silently assuming an answer. No confirmation is ever inferred by default.

Run every command non-interactively instead, with the flags that answer each prompt explicitly:

Non-interactive scan
redential scan --repo . --author you@company.com --yes
Non-interactive submit
redential login   # once, outside CI: the session token persists locally
redential submit --repo . --author you@company.com --yes --confirm-upload

login's device flow itself has no non-interactive mode. Run it once on a machine where you can open a browser, and the stored session (~/.config/redential/credentials.json) is what a later submit --confirm-upload in CI actually uses.

REDENTIAL_SITE_URL (development only)

The CLI talks to https://www.redential.com by default. Set REDENTIAL_SITE_URL to point login and submit at a different server: a local dev instance, or a mock server in tests.

Override
REDENTIAL_SITE_URL=http://localhost:3000 redential login
The stored session records which site_url issued it. If you switch REDENTIAL_SITE_URL after logging in, submit refuses and asks you to log in again rather than silently sending a token meant for one host to another. This is a safety check, not a bug if you see it after changing environments.

Unset it (or don't set it) for normal use. This is a development/testing override, not a setting end users need.

Full command reference: /docs/cli/commands

← CLI overview