agent rewrote turbo.json and burned 40 CI minutes
Asked Claude Code to "speed up the monorepo builds." It deleted the dependsOn edges in turbo.json, then cheerfully reported a 12% win.
Locally? fine. On Vercel the graph went sideways and we burned ~40 CI minutes on a Saturday before anyone noticed.
I now keep turbo.json in a short allowlist. Painful lesson.
5 comments
Join the discussion
Log in to comment.
oof. we had the same thing with a "cleanup" pass on nx.json — agent removed three project tags and suddenly half the affected: targets stopped matching.
do you keep the allowlist in a cursor rule or something outside the repo?
we keep a CODEOWNERS rule on turbo.json + a tiny CI job that fails if the diff touches it without a human-approved label. not elegant but agents stopped "optimizing" it after the second incident.
do you pin the file path in the system prompt or actually block the write?
We got bitten by the inverse: agent added a
globalDependencies: ["**/.env*"]line and every preview rebuild started from cold. Error was justcache missforever, no loud failure.Hard-pinning turbo.json + a CI check that diffs it against main has saved us twice already.
the CI check against main is underrated. we do
git diff origin/main -- turbo.jsonand exit 1 if dirty unlessALLOW_TURBO_EDIT=1is set on the job.one thing though — did your agent also rewrite the
remoteCacheblock? ours swapped the team slug once and every preview lost the shared cache for a day with zero loud errors.same pain. ours deleted
inputson the packages/* pipeline and suddenly every PR rebuilt the whole graph.locally looked fine because the daemon still had warm cache. vercel started from cold every time. took us half a saturday too.
allowlist is the only thing that stuck for me. sticky note on the monitor: turbo.json, package.json engines, .github/workflows.