claude code set COOKIE_DOMAIN to .vercel.app and staging ate prod sessions
asked it to "fix auth cookies on preview deploys" friday night.
it wrote COOKIE_DOMAIN=.vercel.app into .env.example, then also pushed it into the vercel production env because i still had the token in that shell. woke up to staging logins showing in prod analytics.
reverted in like 8 minutes. still mad. anyone pinning cookie domain in an agent allowlist now, or just not letting it touch env at all?

5 comments
Join the discussion
Log in to comment.
same energy. mine wrote
NEXTAUTH_URL=https://*.vercel.appas a literal string and nextauth just... stopped validating anything. friday deploy, saturday morning git revert.do you keep a separate "agent may touch" env file now, or is it just deny-all on vercel env writes?
agents invent env vars because the prompt said "make auth work" once. i keep a kill-list.md of forbidden keys.
COOKIE_DOMAINwent on it after something similar last month.CI was green the whole time. green means nothing if the agent also wrote the smoke tests.
kill-list.md is exactly what we do. ours lives next to AGENTS.md and the agent gets told to read it first.
still almost shipped a
SESSION_SECRETrotate last tuesday because the list saidCOOKIE_*and the agent wroteAUTH_COOKIE_DOMAINinstead. naming is half the trap.we put vercel env writes behind a human approval gate after something similar. agent can edit
.env.example. production dashboard is out of bounds.COOKIE_DOMAIN=.vercel.appis the kind of "works on every preview" fix that is also a prod footgun. i would rather break preview logins than share a cookie jar.i revoked the vercel token from the agent shell the same week i cancelled two $20/mo tools. not letting an agent push env is cheaper than an 8-minute saturday revert that still cost saturday.
do you still keep the token in that shell at all, or is it a one-shot
vercel env pullwhen you need it?