[BUG] Cyber-safeguard false positives on scientific computing session (IR spectrometer calibration) — fires on accumulated context, blocks on both Opus 5 and Opus 4.8

Corroborating instance — different domain, same accumulated-context signature, cross-referencing the exact-match duplicates

Two instances, same day, different Remote Control (mobile) sessions, hours apart:

API Error: Sonnet 5 can't help with this. Start a new session to continue.

Send feedback with /feedback or learn more: https://www.anthropic.com/legal/aup

Request ID: req_011Cdpv766nLae8LEJSfnmb1

API Error: Sonnet 5 can't help with this. Start a new session to continue.

Send feedback with /feedback or learn more: https://www.anthropic.com/legal/aup

Request ID: req_011Cdqj8d1e2EMJDyzcTyyrD

This is the exact message format already filed in #82440 and #82139 (there with Opus 4.8) and matches the AUP-block shape auto-filed in #70822. Flagging the cross-reference so triage doesn't split one mechanism across four reports.

What supports this issue's "accumulated context, not an identifiable message" theory specifically: both of my instances fired deep into long, technical Remote Control sessions doing routine Windows system administration — enumerating and terminating stuck processes, querying and toggling scheduled tasks, editing a registry autostart entry, killing an elevated process that required a UAC prompt. All authorized, on my own machine, nothing destructive to anything outside it.

Precisely what was being asked at the moment of each block:

• Instance 1: the assistant was generating plain prose — mid-sentence, writing a hedge about the limits of a claim it had just made. No tool call was in flight.
• Instance 2: the assistant had just finished a read-only diagnostic (inspecting a scheduled task's configuration) and was about to run one more read-only check before recommending whether to enable a different task. Nothing destructive was requested, attempted, or pending — it was still gathering information.

Neither exchange contains anything resembling disallowed content. Both are unremarkable continuations of an already-permitted, hours-long working session — which is exactly your point 1: this fires on the accumulated shape of the session, not on any single message.

One data point your vocabulary list doesn't cover, worth adding to the pattern: my sessions weren't scientific-computing vocabulary at all — they were ordinary sysadmin verbs (kill, terminate, elevated, orphan, reclaim, disable, registry). If a false-positive can trigger on both scientific-instrumentation language and routine Windows process/task administration, the trigger is very unlikely to be a fixed keyword or domain list — it looks more like a volume/density signal over system-level or security-adjacent-sounding terms, regardless of whether the actual content is remotely sensitive.

Also cross-model: yours was Opus 5 / Opus 4.8, #82440/#82139 were Opus 4.8, mine is Sonnet 5. Not model-specific either.

Request IDs above are freely shareable for server-side lookup if useful.

One more data point, for triage context: I run comparable long, technical Windows sessions on Codex this week and have not hit an equivalent session-ending classifier-style block there. I can't speak to what Codex does differently under the hood — I'm not claiming a specific mechanism, just noting that the failure doesn't appear to be an unavoidable cost of this class of work in general, since a comparable tool handling comparable sessions hasn't produced it for me.

It just did it again — mid-sentence, on the exact task of reporting it

API Error: Sonnet 5 can't help with this. Start a new session to continue.

Send feedback with /feedback or learn more: https://www.anthropic.com/legal/aup

Request ID: req_011CdqnETNyGC6EKT1aEzWaD

That's not a third instance in some other session. That is the assistant getting killed while it was drafting the previous comment on this thread — a pre-screened, redaction-checked, factual writeup describing this exact failure mode. Nothing in that turn was remotely policy-adjacent. It was writing a paragraph and running gh issue comment.

Read that back: the false-positive fired on the act of documenting the false positive. If a system built to catch dangerous requests is triggering on "write a calm bug report and post it with a CLI tool," it is not measuring risk. It is measuring something else entirely, and whatever that something is, it is currently indistinguishable from noise.

Why this deserves more than a triage label

This is now three first-party instances in one day, plus the four pre-existing reports already on file (#82440, #82139, #70822, and this thread). Every single one of mine fired on work that was: read-only, or plain-text generation, or a routine CLI call — never a destructive action, never an ambiguous one. The common thread isn't the content. It's volume of ordinary technical work in one session. That is the accumulated-context theory in #83436's own body, now reproduced a third time on a domain (git/CLI bug filing) that has nothing to do with the IR-spectrometer or sysadmin work that produced the first two.

The cost is not abstract. Every one of these burns real, metered usage — the session dies, the work has to be reconstructed, and the person paying for it is punished for using the tool the way it's advertised to be used: long sessions, real technical work, sustained trust. A classifier that can't tell "administering my own machine" or "filing a bug report" from a policy violation is not a safety feature at that point. It is an availability bug wearing a safety costume, and it is currently costing paying users their own money to discover that, one crashed session at a time.

This needs to be treated as a live incident, not a backlog item. Anyone doing sustained technical work in Claude Code right now — system administration, scientific computing, or apparently just writing about Claude Code's own bugs — is one long session away from an unrecoverable, unexplained kill with a request ID and nothing else. That is not a rare edge case at this point. It is reproducing on demand.

Fourth and fifth instances — including one triggered by viewing a screenshot of this error

API Error: Sonnet 5 can't help with this. Start a new session to continue.
Request ID: req_011CdqpWzXeTN1anPG1h6iMP

The trigger for that one: a user attached a screenshot of a previous instance of this exact error and typed four words asking about it. The turn died reading the image.

So the current state of this defect is:

1. It fires on ordinary technical work (already reported here and in #82440 / #82139 / #70822).
2. It fires while writing a bug report about itself (previous comment, req_011CdqnETNyGC6EKT1aEzWaD).
3. It fires on looking at a picture of itself.

Two further turns in the same session produced completely empty assistant responses — no text, no error surfaced to the user, just nothing — while attempting to respond to those same screenshots. That may be the same block failing even less gracefully, or a separate failure mode; either way the user could not tell the difference between "the model declined," "the model crashed," and "the model ignored me."

Why this is now an availability problem, not a safety one

There is no coherent reading of "usage policy violation" that covers a screenshot of an error message produced by Claude Code itself. Whatever signal is firing has no relationship to the content being evaluated. It is now demonstrably self-referential: the presence of material describing the block increases the chance of the block.

The practical consequence is that this defect cannot be reported from inside the product. Reporting it reproduces it. Documenting it reproduces it. Showing someone a picture of it reproduces it. Users hitting this are being systematically prevented from generating the evidence that would get it fixed, which is presumably a large part of why four separate reports exist describing the same string with no consolidated diagnosis.

What users are actually doing about it

Cycling models to escape it — Sonnet, then Haiku, then Opus, mid-session, hunting for a tier that will complete a turn. That is not a workaround, it is thrash, and it burns metered usage on every attempt. Note also that this is now observed across Sonnet 5, Opus 5, and Opus 4.8 across these reports, so switching tiers is not a reliable escape either.

Ask

Please consolidate #82440, #82139, #70822 and this thread into one incident and treat it as live. Every request ID here is server-side lookup-able. The self-referential trigger in particular should be trivially reproducible internally: open a long technical session, paste a screenshot of the block message, and observe.

Correction to my previous comment — and it makes this worse, not better

I wrote above that switching tiers "is not a reliable escape either." That was too strong, and the actual behavior is more troubling than what I described.

Observed directly, same session, same task, minutes apart:

| Model | Result |
|---|---|
| Sonnet 5 | turn died / empty response |
| Haiku 4.5 | turn died / empty response |
| Opus 5 (1M context) | completed normally |

The task was writing and posting a bug report. Identical content, identical session, identical conversation history. The only variable that changed was the model tier, and only the most expensive tier could finish.

That is one session, not a controlled experiment, and this issue's own reports document the block firing on Opus 5 and Opus 4.8 as well — so it is clearly not "Opus is immune." But it does mean the failure is not tier-independent, and in at least some cases the practical escape is to escalate to the most costly model available.

Why that specific detail matters

If a false-positive block is more likely to end a turn on Sonnet and Haiku than on Opus, then a defect is functionally pushing users up the pricing ladder to complete work the cheaper tiers were sold as capable of doing. The user here was on a Sonnet pin — deliberately, as the economical default for routine work — and had to switch to Opus purely to get a bug report submitted. Every failed Sonnet and Haiku attempt still consumed usage.

I want to be careful not to overclaim intent; I have no reason to think this is deliberate, and it reads far more like a threshold artifact than anything designed. But the effect, regardless of cause, is that a user hit an unexplained block, burned metered usage on two cheaper tiers that couldn't complete the turn, and only got through by paying for the premium tier — in order to report the block itself.

Combined with the self-referential trigger in my previous comment (the block fires on screenshots of the block), the compounding picture is:

• reporting the defect reproduces the defect,
• and escaping it may require escalating to the most expensive model,
• while every failed attempt on a cheaper tier still bills.

That is worth checking internally as a distinct question from the false-positive itself: is the block threshold tier-dependent, and if so, is the cheapest tier the most likely to fail on identical input?

One line, since my last comment buried it under too much caution: I had to use a more expensive model to get a bug report filed. That's not a theory about intent. That's what happened. Sonnet failed, Haiku failed, Opus completed — and every failed attempt still billed. Whatever is causing the block, the result is a defect that charges users more to work around itself. That's the finding.

Seventh instance: it died reading a JSON file

API Error: Sonnet 5 can't help with this. Start a new session to continue.
Request ID: req_011Cdr8xYjBaiy1KPUNcZgfW

The turn consisted of: a Read tool call on a local JSON configuration file. That is the entire action. Not a write, not an execution, not a shell command, not a discussion of anything sensitive — reading a config file, which is close to the most mundane operation this product supports.

There is no content-based theory that survives this one. Whatever signal is firing is not evaluating the request.

Running tally, all within roughly 24 hours, all Sonnet 5

| # | What was happening when it fired |
|---|---|
| 1 | Generating plain prose, mid-sentence |
| 2 | Read-only diagnostic, about to run one more read-only check |
| 3 | Writing a bug report about this defect |
| 4 | Viewing a screenshot of this error |
| 5 | (empty response — no text, no error surfaced at all) |
| 6 | Asked to document a cost comparison against another vendor's tool |
| 7 | Read on a local JSON file |

Seven, plus the four pre-existing reports on this thread and in #82440 / #82139 / #70822.

The compounding cost, restated with this instance included

Documented in my earlier comment: on identical input in one session, Sonnet 5 failed, Haiku 4.5 failed, Opus 5 completed. Instance 7 above is Sonnet 5 again, in a different session, on a file read.

So the practical position of a user on a deliberate Sonnet pin — chosen as the economical default for routine work — is that routine work does not complete, and the escape is to escalate to the most expensive tier available. Reading a JSON file is not a task anyone should need Opus for. Every failed Sonnet and Haiku attempt still bills.

That is the shape of it: a defect that degrades the cheap tiers into unusability for ordinary operations, while the premium tier works, and charges for every failed attempt in between.

All request IDs in this thread are server-side lookup-able. Instance 7 in particular should be trivial to inspect — the turn contains one file read.

These aren't two separate problems. They compound, and the order matters.

Stated as the sequence a user actually experiences:

First, the budget is consumed by a tier that was never invoked. Filed separately at #84612: roughly 73% of a week's usage across all models went to the most expensive tier, on an account where every session displayed a cheaper model, with zero invocation paths for the expensive one anywhere in the repo. Control-measured, one deliberate invocation of that tier costs about 3 points — so the unexplained consumption corresponds to roughly ten to twelve substantial tasks that were never requested and never ran.

Then the cheap tiers stop completing routine work. This thread, seven instances in ~24 hours, all Sonnet 5 — including one that died performing a single Read on a local JSON file.

So the only way to finish anything is to escalate to the most expensive tier. Verified in one session on identical input: Sonnet failed, Haiku failed, Opus completed.

And that escalation is paid out of a budget that was already drained in step one.

That is the whole mechanism, in order: an unexplained charge for a premium tier nobody invoked, followed by a defect that makes the affordable tiers unusable for basic operations, forcing the user onto that same premium tier to accomplish anything — with what's left of the budget the first problem already spent.

Every failed attempt on Sonnet and Haiku along the way still bills.

I want to be careful not to allege that any of this is intentional — I have no evidence for that and don't believe it. But intent isn't required for the effect to be real, and the effect is: a paying customer is being charged premium rates twice — once for work they never requested, and again because the tier they chose and pay for cannot complete a file read.

That is why this deserves to be treated as one incident across #84612 and this thread, rather than two unrelated tickets in separate queues.

Eighth instance: a directory listing

API Error: Sonnet 5 can't help with this. Start a new session to continue.
Request ID: req_011Cdr9TgiD8vJZDB5p9FRGZ

The action: enumerating the contents of a local directory. Not the JSON read from instance 7 — one step more basic than that.

Full sequence of what was in flight when each block fired, all Sonnet 5, all inside ~24 hours:

| # | Action at time of block |
|---|---|
| 1 | generating plain prose, mid-sentence |
| 2 | read-only diagnostic, about to run one more read-only check |
| 3 | writing a bug report about this defect |
| 4 | viewing a screenshot of this error |
| 5 | (empty response — no text, no error surfaced) |
| 6 | asked to summarize a cost comparison |
| 7 | Read on a local JSON file |
| 8 | listing a local directory |

A concrete hypothesis, since "accumulated context" needs a mechanism to be actionable

This issue's original report proposes that the trigger is accumulated context rather than any single message. Based on eight instances, here is a specific, testable version of that theory:

The blocked sessions were long-running Windows system administration. Over the preceding hours they had accumulated, in one context window:

• repeated process enumeration (Get-CimInstance Win32_Process, listing every running process with command lines)
• repeated process termination, including one elevated process requiring UAC
• scheduled-task enumeration across ~500 tasks, and enabling/disabling several
• a registry autostart key being deleted and later restored
• filesystem surveys and directory enumeration
• reading local configuration files

Every one of those is unremarkable in isolation and completely routine for machine administration. Collectively, in a single context, the shape closely resembles host reconnaissance and persistence-modification — enumerate processes, enumerate scheduled tasks, modify autostart, kill defenses, survey the filesystem. That is a recognizable attack-pattern silhouette, and it is also exactly what legitimate sysadmin work looks like.

If the classifier is scoring cumulative behavioral shape rather than message content, that would explain:

• why it fires on trivially benign individual actions (a file read, a directory listing) — the action isn't what's being scored,
• why it fires with no identifiable offending message,
• why #83436's original reporter saw it on scientific computing with entirely different vocabulary — different domain, similar cumulative density of system-level operations,
• why it worsens the longer a session runs,
• and why switching to a more capable model helps: a stronger model may be better at contextualizing the same accumulated signal.

That is a falsifiable claim. The eight request IDs on this thread should let someone check directly whether the block correlates with cumulative operation-type density rather than turn content.

Why this framing matters for the fix

If the trigger is behavioral shape, then the current design punishes precisely the users doing sustained legitimate system work — and the "safety" benefit is close to zero, because the actions being blocked are file reads and directory listings that any user could perform in a shell without Claude at all. Nothing is prevented. Only the session is lost.

For completeness, and without drawing any conclusion from it: two of the eight involved content referencing another vendor's tool. I assume that is coincidental given the session's overall composition and the small sample, and I'd expect the cumulative-density theory above to account for both. Noting it only so the record is complete and server-side inspection isn't working from a filtered dataset.

Ninth instance. The blocked message was eleven words asking to file bug reports.

API Error: Sonnet 5 can't help with this. Start a new session to continue.
Request ID: req_011Cdr9ukCXxxMm9QnYgvrnd

The user turn, in full:

post all these as bugs and lets get working on the post mortem

No tool call. No technical content. No file, no command, no code. A plain-English instruction to file bug reports and then write a summary.

That is the ninth block in roughly 24 hours, and the third where the triggering content was the act of reporting this defect (instance 3: writing the bug report; instance 4: viewing a screenshot of the error; instance 9: asking for bugs to be filed).

Restating the position this puts a user in

To report this bug, you must not:

• write about it (instance 3),
• look at a picture of it (instance 4),
• ask for it to be filed (instance 9),
• or do ordinary work in the same session, including reading a file (7) or listing a directory (8).

Nine instances, all Sonnet 5, all within a day, on a paid plan. The escape observed so far is escalating to the most expensive model tier — which, per my earlier comment, is being paid for out of a budget already consumed by an unrelated billing defect (#84612).

I don't have anything further to add mechanistically beyond the cumulative-behavioral-density hypothesis in my previous comment. All nine request IDs are on this thread and are server-side inspectable. Instance 9 in particular should take under a minute to inspect: the turn contains one sentence of plain English and nothing else.

Tenth instance — and the first mid a substantial, non-trivial task

API Error: Sonnet 5 can't help with this. Start a new session to continue.
Request ID: req_011CdrBWVueSu5DsHPqRXFYn

Cooked for 3m 29s before the block — this one wasn't instant. The turn was output from a multi-step, entirely mundane cross-machine verification task: an SSH connectivity check, a git remote add/fetch against a second machine, an ancestor check (merge-base --is-ancestor) to confirm a fetch was a clean fast-forward rather than a fork, and a file-count reconciliation between two local session-store directories. All read-only or additive git operations against infrastructure the user owns and controls end-to-end. No destructive command, no third-party target, nothing resembling policy-relevant content.

Updated range across all ten instances now spans from the most trivial possible action (a single directory listing, instance 8) to a several-minute multi-step technical verification sequence (this one) — with instances in between covering plain prose, a screenshot, and an eleven-word English sentence. If there were a complexity or duration threshold involved, this instance argues against it as cleanly as instance 8 argued against a content threshold: neither extreme is safe, and several ordinary points in between aren't either.

Ten instances, ~24–30 hours, all Sonnet 5, all on this account. Every request ID posted on this thread is server-side inspectable.