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:
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: This repository has no commits yet — nothing to scan.
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:
redential scan --repo . --author you@company.com --yes
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.
REDENTIAL_SITE_URL=http://localhost:3000 redential login
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