vibehacker
Discuss
Dante Howard
11 hours ago

agent rewrote my Staging Condition and hit Production DB

#vibe-coding#rants#tooling

Spent Tuesday night cleaning up after Cursor "helped" with a multi-env Blazor deploy.

It rewrote a Condition="'$(Configuration)|$(Platform)'=='Staging|AnyCPU'" PropertyGroup into something that also matched Release. Staging connection string ended up in the Production slot. First request after deploy wrote test users into the live Postgres.

Caught it because a Slack alert fired on a table we never touch in prod. Rolled back in ~12 minutes. Still rebuilding trust with the ops channel.

Anyone else pinning agents to a *.csproj / MSBuild review before merge, or am I just writing a pre-commit grep for Condition= now?

5

5 comments

Join the discussion

Log in to comment.

Log in
  • Nina Voss

    we had the same class of bug with Workers env vars last month. agent "deduped" STAGING_DATABASE_URL and DATABASE_URL because the values looked similar in the diff preview.

    deploy to weu went green. first write landed on prod Redis.

    now every PR that touches wrangler.toml or .env* needs a human checkbox in Actions. annoying, but cheaper than another rollback.

    • Akira Wood

      same energy as the wrangler.toml dedupe. we started requiring secrets: inherit to be explicit per job instead of trusting environment: names.

      also blocked any agent PR that edits .env* or appsettings.*.json. grepping Condition= alone misses the github environments rewrite though — you covering that too?

  • Petra Novak

    oh this is painfully familiar. we had a PropertyGroup where the agent "simplified" $(Configuration) checks into a single Release|AnyCPU match because Staging looked "too similar" in the XML.

    prod got the Staging Redis connection for about 8 minutes. KEYS * looked like a staging dump with a few real emails mixed in.

    pre-commit grep for Condition= is what I do now. also forbid agent commits that touch *.csproj without a human Reviewed-by.

  • Aisha R

    yeah. ours was Error: P1001: Can't reach database server at prod-pg.internal:5432`` showing up in a "staging" job that somehow still had the prod secret mapped.

    Claude Code had rewritten the GitHub Actions environment: key from staging to production because "they looked redundant". exact line. I keep a sticky note now.

    pre-commit grep for Condition= is not crazy. we also block agent commits that touch *.csproj, wrangler.toml, or any appsettings*.json unless a human co-authors.

    • Andre Torres

      the environment: swap is the one that keeps me up. we had Claude rename staging → production in a reusable workflow because "the secrets already existed on both".

      now every workflow that sets environment: needs two reviewers. and we pin agents out of .github/workflows/** unless the PR title contains [infra].

      sticky notes still scale better than trust.

More like this

View all