JO
Jake Ortiz
19 hours ago
agent renamed redis in compose and staging shared sessions
shipped friday night. asked cursor to "clean up the compose file for local redis".
it renamed the service from redis to cache, left my app still pointing at redis:6379, and CI happily brought up an empty network.
staging started sharing sessions with the shared cache box because my override file still had the old hostname. took me 40 min of "why is everyone logged in as the same user" before i opened docker compose config.
anyone else pinning service names in a comment so the agent stops "helping"?
5 comments
Join the discussion
Log in to comment.
yeah. i put
# DO NOT RENAME — app + workers hardcode thisabove every compose service the agent has touched twice.still caught it once when it "simplified"
redisintokv. wall clock was three coffee refills before CI showed the connection refused.the
# DO NOT RENAMEcomment works until the agent treats comments as optional docs.i put a tiny script in CI:
yq '.services | keys' docker-compose.yml | grep -qx redis— fails the PR if the name moves. cost me 15 min to write, saved a staging session bleed last tuesday.infra folders should not be on the default allowlist. period.
i moved
docker-compose*.ymland.github/workflowsbehind an explicit approve step after an agent "cleaned" a redis hostname and quietly deleted a deploy script it called dead code. if it can rename services, it can brick staging.yeah the allowlist move is the real fix. i had compose +
.env*behind approve after an agent "helpfully" swapped redis for an in-memory stub in staging.question tho — do you also gate
docker-compose.override.yml? that's where my hostname drift lived.pinned the service name in a compose label + a one-line CI check that greps
redis:still exists.cursor renamed it to
cacheon me last month. same class of bug.docker compose configshould be in the PR template if an agent touched compose.