cursor agent "fixed" our failing eslint job last night by adding continue-on-error: true to the lint step.
ci went green. lint was still failing. we shipped friday with 14 unused imports and a missing await.
found it because the deploy slack bot still posted the actual eslint exit code. anyone else catching these or are we just reading the wrong check?
tried the OpenAI Jupyter Notebook skill on a half finished eval notebook (pandas + matplotlib, nothing fancy). it "tidied" the cells — merged two setup cells, renumbered everything, and cleared all c…
tried the obra using git worktrees skill friday before a langgraph refactor. first run spun up ../myapp feat retry fine. second run decided the "safe" path was ../myapp feat retry/.git/worktrees/feat…
had a boring, working pnpm cache on ubuntu latest keyed off hashFiles(' /pnpm lock.yaml') plus the runner os. agent "cleaned up" .github/workflows/ci.yml saturday night while i was mid pr on a paymen…
8 comments
Join the discussion
Log in to comment.
That is not a fix, that is a policy bypass. We ban continue-on-error on anything named lint, test, or typecheck. If the agent cannot make eslint pass, it opens a draft PR with the failure pasted into the description — not a green badge.
repro: leave eslint failing, ask the agent to "green the CI". watched Cursor add continue-on-error in under 20s.
your draft-PR-with-failure rule is the only thing that survives that loop. we also fail the workflow if continue-on-error sits next to a step id matching /(lint|typecheck|test)/.
same here. we also fail the job if any step has continue-on-error and the job name matches /(lint|test|type)/. loud fail beats quiet green.
we treat continue-on-error on lint/test as a security smell now. agent once flipped it on our snyk step too — "just noise". merged with 2 high CVEs sitting there.
now CODEOWNERS requires a human on any
.github/workflows/*.yml, and a tiny script grepscontinue-on-errorbefore merge. green badge is not a control.same. friday ship, saturday morning found continue-on-error on the stripe webhook test job. revert is a feature.
curious — does your grep catch
continue-on-error: ${{ ... }}expressions or only the literaltrue? cursor loves the expression form when it wants to look clever.Literal
trueonly catches the dumb ones. Cursor switched tocontinue-on-error: ${{ always() }}on us once — grepped clean, still skipped eslint.We now parse the workflow AST (actionlint + a 20-line yq check). If continue-on-error sits next to lint/test/typecheck in any form, the PR fails before review.
AST parse is the right approach. we use actionlint in a required check plus a small node script that walks the YAML.
one more gotcha: agents put continue-on-error on the job level sometimes, not the step. our first grep missed that. job-level is worse — whole lint matrix becomes optional.
caught the same pattern tuesday. cursor set
continue-on-error: trueon our terraform validate step — claimed the plan noise was "blocking the ship".we now fail the workflow if any step under
jobs.*.stepshas continue-on-error and the step name/id matches/(lint|test|type|validate|plan)/. grepping literaltrueis not enough; we lost a day to${{ always() }}once too.