# The agent renamed the environment variable in code, but CI still held the old secret name

The agent was asked to clean up a cryptic legacy token name. It renamed the variable in source code, updated every read it could locate, removed the old spelling from comments, ran the app locally, saw the authenticated call succeed, and committed. Tests were green and the local dotenv file still carried the old alias, so the change felt complete. The first deployed run told a different story: CI registered the secret under the legacy name, the code read the new name, got undefined, and the first real upstream call failed.

The agent's blast radius stayed inside the repository. It renamed a string it could read, but the binding lives in places the repo does not contain: the CI secret store, the deployment manifest, the hosting dashboard, another service that injects the token, and the operator documentation that tells people where to set it. A find-and-replace in code cannot touch any of those.

## The name lives outside the repo as well

**Source code reads the variable; an external store holds it.** The name on the right side of a process.env lookup must match the name under which the secret was actually registered. Renaming the lookup without renaming the registered secret produces a silent undefined, not a clean error.

**The local dotenv file accumulates keys over years.** The legacy alias often still sits beside the new name in .env, so a local run satisfies both reads and the rename changes nothing observable on the author's machine.

**Tests rarely exercise real env resolution.** Fixtures define the value or mock the client, so unit and integration suites pass whether the deployed secret exists under the new name or not. Green tests prove the code path works; they do not prove the external store was updated.

## Treat a rename as a coordinated cutover, not a find-and-replace

**Enumerate external references before deleting the old name.** Check CI variable sets per environment, the Kubernetes or Helm env block, the platform secret dashboard, any cross-service injection, and the docs operators follow. Every one has to agree on the new name.

**Keep an alias across one release.** Read the new name first, fall back to the old name, and log the deprecation. Move the external store to the new name together with the code, so neither side runs alone.

**Fail fast on a required variable at startup.** Print which required variables are present and which are missing, instead of letting an undefined value travel downstream until a mysterious auth failure surfaces at runtime.

**Verify the rendered deployment environment in staging.** Run against the same secret set CI and production use rather than the local dotenv file; a missing key shows up at boot, not on the first customer request.

Agents clean up the strings they can see, and assume the rest of the contract moved with them. Where has a rename inside the repo already outrun the secret that still lives under its old name?