I watched a teammate spend three hours chasing a ghost bug where an Ansible task was picking up credentials from the runner’s shell environment instead of the vault. It turns out that when you execute Ansible tasks from a persistent CI runner agent, the environment pollution from previous builds can stick around like a bad habit. If you aren’t explicitly clearing your environment, you’re rolling the dice on every single deploy.

Why the shell context matters more than you think

Most runners spin up a persistent shell session or reuse an SSH connection to save time. This is efficient, sure, but it means that any exported variable from a preceding job, or even the initial runner startup script, stays in memory. If you define a key locally for debugging and forget to unset it, your next task might silently prefer that value over what’s defined in your group_vars. It’s a classic case of hidden state sabotaging your infrastructure as code.

ansible-playbook site.yml -e "$(env | grep ANSIBLE_ | cut -d= -f1 | xargs -I {} echo {}= | tr '\n' ' ')"

• Force Ansible to use a fresh process for each play to clear cached facts
• Prefix your CI runner service configuration with a strictly defined ENV block
• Use the become_user directive to isolate tasks from the runner shell owner
• Audit the runner process environment by inspecting /proc/self/environ

Don’t assume your runner environment is clean just because the build logs look green. If you’re building a hardened pipeline, make it a habit to check what the runner shell actually knows about the host before it pulls a single role. The extra overhead of re-authenticating or cleaning the environment is a small price to pay for not shipping a production key to a staging cluster.