CLI command works locally but fails in CI: what to compare first

When a CLI command works locally but fails in CI, compare environment, working directory, installed versions, and hidden input before changing the command itself.

Local success often relies on state that CI does not have: a cached login, a default config file, an untracked .env value, a global package, a different shell, or a current directory that happens to contain the right file. The CI log may show the same command, but the context around the command is different. Treat the command plus its environment as the real unit to inspect.

Start with four checks. Print the tool version and runtime version. Print the current directory and list the expected files. Confirm every required environment variable by name without exposing secret values. Finally, run the command with the same flags and non-interactive mode that CI uses. If the CLI has a verbose or dry-run mode, use it to show which config file and endpoint it selected.

Do not assume the fix is to add retries. Retries hide timing problems but do not fix missing credentials, wrong paths, or incompatible versions. Also avoid copying a local config into CI unless the team has decided it belongs there.

The practical outcome should be a comparison table: local value, CI value, expected value, and whether the difference matters. That table usually reveals the real mismatch faster than another round of command edits.

CLI command works locally but fails in CI: what to compare first

// COMMENTS

ON THIS PAGE