CLI command works locally but fails in CI: shell and environment checklist

When a CLI command works locally but fails in CI, compare the execution environment before assuming the tool or application code is broken.

Begin with the exact command and shell. A command written for bash may fail under sh. A PowerShell command may quote arguments differently than cmd. Globs, environment variable syntax, path separators, and multiline scripts are common sources of drift. Print the shell name, working directory, and runtime versions before the command runs so the failure has context.

Then compare files and dependency state. CI may check out a shallow clone, skip generated files, use a different package manager, restore an old cache, or run from a subdirectory. If a lockfile is ignored locally or line endings changed on checkout, the command may behave differently even though the repository looks similar.

Next compare environment variables and permissions. Local machines often have hidden credentials, global config files, writable temp directories, or preinstalled binaries. CI jobs may need explicit secrets, PATH entries, timezone, locale, or network permissions. Do not paste secret values into logs; print only whether required names are present and which branch of config loaded.

A good CI failure note includes the exact failing command, shell, working directory, OS image, runtime versions, first failing line, and one local reproduction attempt using the same shell. That turns “works on my machine” into a checklist rather than a dead end.

If the difference is real, fix the command to be explicit: set the working directory, pin runtime versions, choose the shell, and replace implicit local state with checked-in or configured inputs.

CLI command works locally but fails in CI: shell and environment checklist

// COMMENTS

ON THIS PAGE