CLI command works locally but fails in CI: checks before changing code

When a CLI command works locally but fails in CI, check environment, working directory, shell, installed versions, and secrets before changing application code.

Local success can hide assumptions that CI does not share. The command may rely on a global package, a cached build file, a local `.env`, a different Node or Python version, a path with spaces, a shell-specific expansion, or credentials stored in a user profile. CI starts from a cleaner machine, so those assumptions become visible.

Begin by printing the command, working directory, runtime versions, package manager version, relevant environment variable names, and file paths that the command reads. Do not print secret values. Compare local and CI dependency installation logs. If the command uses glob patterns, path separators, or quoted arguments, test the exact shell used by CI. PowerShell, bash, and cmd can treat the same text differently.

Next, separate setup failure from command failure. If dependencies were not installed, changing the command will not help. If the command cannot find a config file, inspect the checkout path and working directory. If authentication fails, check whether the secret is available to the CI event type, especially for forks or scheduled jobs.

Only change application code after the environment is proven equivalent. Many CI-only failures are not product bugs; they are undocumented local assumptions. The fix is often a pinned version, explicit working directory, checked-in config template, or clearer command wrapper.

CLI command works locally but fails in CI: checks before changing code

// COMMENTS

ON THIS PAGE