Stop .env Drift Before Merge with Wizard of Drift

I shipped a small GitHub Action this week: wizard-of-drift.

It catches .env* key drift in pull requests and leaves a review comment with concrete fixes.

It uses Warp Oz under the hood to do the review, and it works great.

Why

Teams with multiple env files (.env, .env.production, .env.staging, etc) slowly drift.

Someone adds TWILIO_API_KEY to one file and forgets the others. CI passes, deploy goes out, and then something breaks in preview or prod.

Wizard of Drift catches that in the PR before merge.

The Real Problem

Most env drift bugs are boring and expensive:

• local works, preview fails
• preview works, production fails
• one service has a key, another service does not

And they are hard to catch in code review because reviewers are focused on app code, not checking every .env* file by hand.

Even worse, the PR diff can hide this. If a new key is added in .env.production only, nobody notices until a runtime path hits missing config.

This is the kind of failure that burns hours for no good reason.

What It Checks

• Scans .env* files in the repo
• Excludes .env.keys (never commit that)
• Compares key names only (not values)
• Handles DOTENV_PUBLIC_KEY naming rules per file:
  • .env expects DOTENV_PUBLIC_KEY
  • .env.<target> expects DOTENV_PUBLIC_KEY_<TARGET_UPPERCASE>
• Posts a PR review summary with missing key lines to add

Add It In 30 Seconds

name: Env Drift Review

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  env-drift:
    runs-on: ubuntu-latest
    steps:
      - uses: dotenvx/wizard-of-drift@v1
        with:
          warp_api_key: $
          github_token: $
          warp_agent_profile: "" # optional

Why Oz Works Well Here

This is a great use case for an agent because the input is high-context but bounded:

• list of env files
• extracted key sets
• the .env* diff in the PR
• explicit rules about DOTENV_PUBLIC_KEY naming

Wizard of Drift builds that context first, then gives Oz a tight prompt and asks for one output: a concise review summary with exact keys to add.

That pattern matters.

Oz is not guessing from vague code context. It is reviewing a purpose-built context document generated by CI, then returning actionable output directly into the PR conversation.

So the reviewer sees concrete fixes, not generic AI advice.

The Bigger Idea

This is the kind of workflow I want more of:

• static CI context
• AI agent review
• deterministic output in PR comments

Oz helps amplify what Dotenvx is already good at: making .env workflows safer and easier to operate at scale.

Dotenvx gives you the secure env model. Oz gives you a practical enforcement loop at review time.

Together, they remove a class of annoying config breakages before they merge.