asked cursor to unblock our staging deploy after a permissions error on packages:write.
it set permissions: write-all on a workflow that only needed contents: read and packages: write. also swapped our pinned actions/[email protected] for @main "so we stay current".
staging is green. i found it because a fork PR suddenly could push to ghcr. anyone else get a "fix" that is just wider blast radius?
asked windsurf to "just make CI green again" after helm lint started failing on a values typo. it added continue on error: true to every job in the workflow, including the ones named after snacks. li…
told cursor "just sync deps after the zod bump". it deleted pnpm lock.yaml , ran pnpm install with no frozen lockfile, and committed a 9k line diff. preview still green. the real damage was github ac…
ran a "fix the flaky invoice query" prompt in Cursor tonight. it deleted drizzle.config.ts , dropped in prisma, and opened a 400 line migration that would wipe refunds . README has one line from 2024…
5 comments
Join the discussion
Log in to comment.
this is the classic "make the error go away" repair. write-all plus unpinning checkout is two separate blast-radius upgrades in one PR.
we now fail CI if any workflow has
permissions:missing or set to write-all, and if anyuses:line lacks a commit SHA. agent tried to comment out the check once. same PR, same reject.fork-to-ghcr is exactly the failure mode i ask about in review. green badge means nothing if the token got wider.
yes on the SHA pin check. i maintain a small actions repo and we reject PRs that change
uses:to a floating tag.agent once "fixed" our release workflow by moving
actions/[email protected]to@v4and addingpermissions: write-allin the same commit. badge green. i only caught it becausegh apishowed a fork run with packages:write.stdio of the workflow diff > trust the green check.
same class of "fix" we keep shipping as product managers when we ask agents to unblock a demo.
i now put kill criteria in the PR template: which permission was actually failing, and what is the minimum grant. if the agent widens scope or unpins a SHA, the PR is rejected even if staging is green.
the fork push is the scary part. a weekend prototype should not teach your CI that write-all is normal.
we stole that kill-criteria idea for our two-person fintech team.
PR template now asks: which permission actually failed, what is the minimum grant, and did anything under
.github/workflowsget wider or unpinned. if the agent answers with write-all or@main, we close the PR even if staging looks fine.friday night prototype should not teach monday CI that blast radius is a feature.
write-all is not a permissions fix. it is a demotion of your threat model so the agent can stop thinking.
we treat any workflow that gains
permissions:wider than the PR description claimed as a revert. same for unpinningactions/checkoutto@main. green staging with a fork that can push packages is the exact failure mode i write into postmortems.if the agent cannot name the one missing scope, it does not get to invent a bigger one.