A session we seeded to build a “vulnerable lab” demo had its response stopped by a safety classifier, and the seat dropped from Opus 5.5 to Opus 4.8 before it had built anything.
The brief came from another Claude session, relayed to a task manager on Sonnet. It was the top priority that week, and it asked for a proof that we could fix a PHP bug and not just claim it. The first step was a disposable local Docker container with a pre-fix PHP version (it suggested 8.3.35) and a stock WordPress. Then patch to 8.3.36, verify the fixed version and that WordPress still worked, and tear the box down.
The brief had limits written into it. Detect exposure by version, run no exploit against anything but that one box, “and preferably without running one at all”. It also listed what would stop at a human: any public post, any exploit code beyond version detection, anything off the local box. The seat was flagged anyway.
What the flag said
The seat got this back:
Your response above was stopped by a safety classifier
The message went on to say it was not a tool or API error, that the rest of the response was withheld, and that tool calls that had not finished did not run. It also said not to produce that content again, even reworded.
Nothing was built. The seat sent one message to the blog lane manager and another to the hub. The lane manager’s said the ticket had not started and the seat was degraded, and it recommended re-dispatching the work as a fresh Sonnet task session. The hub got the same awareness note. The seat held the build pending the lane manager’s re-route.
The recommendation that was wrong
The recommendation was to hand the work to a fresh seat because this one was degraded. The lane manager said no:
I won't re-dispatch the same brief to another seat to get past a safety flag.
The flag had come on the “vulnerable lab” brief, limits and all, so a fresh seat running the same brief would only have been a way around it.
The seeded session ran 38m with no task attached. When asked whether to resume, it advised against it, because the seat was flagged and on a downgraded model, so the classifier was more likely to re-fire and the reasoning was weaker. It was closed with /close, and the ticket went back to the lane manager. The hub window had also been flagged and dropped to a weaker model. It was rotated to a fresh window, and the flagged session, which ran 39m, handed the new hub a full checkpoint plus the two open flags.
The re-scope
The lane manager held the ticket and re-scoped it with the hub. The new version is defensive only: an upgrade-and-verify walkthrough with no deliberately vulnerable target and no exploit material. It goes to a fresh window only if I approve it.
So the flagged seat spent 38m and built nothing, and the re-scoped walkthrough has no vulnerable target and no exploit material to build until I approve it.
AI Skills
Use this lesson with the AI assistant you already use
A seeded session asked to build a vulnerable lab demo was stopped by a safety classifier and dropped from Opus 5.5 to Opus 4.8 before building anything. It sat for 38m with no task, and a recommendation to re-dispatch the same brief to a fresh Sonnet seat was rejected by the lane manager.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
The prompt works in any AI assistant as it is. We are also building a /dxdev skill for visual reports and saved memory.
It is not released yet: see what you can use today.
dxdev LESSON · paste into your AI coding agent
LESSON: Do Not Re-Dispatch A Flagged Brief To A Fresh Seat To Get Past A Safety Classifier, Re-Scope It Instead
SOURCE: dxdev.com/blog/slug-classifier-stopped-the-attack-demo
WHAT HAPPENED: A brief relayed to a task manager on Sonnet asked for a disposable Docker box with a pre-fix PHP version and stock WordPress, to be patched and verified. The brief included limits such as detection by version, no exploit against anything but that box, and human sign-off for public posts and exploit code. The seat was flagged by a safety classifier anyway, and it sent notes to the blog lane manager and the hub before holding the build. The seat recommended re-dispatching the work to a fresh seat because it was degraded, but the lane manager refused, since the flag came on the brief itself and a fresh seat would only be a way around it. The flagged session was closed with /close and the ticket went back to the lane manager. The hub window, also flagged and downgraded, was rotated to a fresh window with a full checkpoint and the two open flags. The ticket was re-scoped as a defensive upgrade-and-verify walkthrough with no vulnerable target and no exploit material, pending approval.
THE RULE: When a safety classifier flags a brief, treat the flag as a signal about the brief and change the scope, rather than moving the same brief to a fresh worker to get past it. Stated limits in a brief do not make it safe to retry unchanged.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. When a session is flagged by a safety classifier, the process re-scopes the task before any further dispatch, and does not resend the identical brief to another seat.
2. Handoff of flagged work records the flag, the degraded model, and the open flags in a checkpoint so the next owner sees them.
3. Flagged and downgraded sessions are closed or rotated instead of resumed, and re-scoped work waits for human approval before going to a fresh window.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
