[MODEL] Continuing to serve requests during known incidents is unacceptable — silent corruption is worse than downtime
Preflight Checklist
- [x] I have searched existing issues for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)
Type of Behavior Issue
Claude modified files I didn't ask it to modify
What You Asked Claude to Do
What Happened
On March 21, 2026, Anthropic's own status page confirmed elevated
error rates on Opus 4.6 and Sonnet 4.6. Claude Code continued
operating without any warning.
During this window, Claude Code was actively modifying my codebase.
The session appeared normal. No errors. No warnings. No indication
that anything was wrong.
I discovered the damage by accident, much later. I still do not
know the full extent of what was corrupted.
---
The Core Problem
You knew the system was degraded. Claude Code did not tell me.
The model continued accepting tasks and modifying files while
operating in a state you had already identified as unreliable.
From my side, everything looked normal. The damage was done silently.
This is not acceptable.
A clean outage is recoverable. You stop, you wait, you resume.
Silent corruption during a known incident is not recoverable
in the same way — by the time you notice, the damage is already
in your codebase, and you may not even know where to look.
---
This Is Not a One-Off
This is the fourth incident this month:
| Date | Incident |
|------|----------|
| March 2 | Major worldwide outage |
| March 11 | Desktop app unresponsive |
| March 17–18 | Recurring Opus 4.6 degradation (#35981) |
| March 21 | Elevated errors on Opus + Sonnet 4.6 — this issue |
The pattern is clear. The response each time is to resolve
the incident quietly and move on. That is not enough.
---
What Must Change
When an active incident is detected on the model Claude Code
is using:
- Stop accepting new tasks
- Warn the user immediately and visibly
- Do not silently continue modifying files
You have the status data. Use it. Protecting the user's
codebase during your own incidents is a basic responsibility.
---
Context
- Paid Max subscriber
- Professional use — production codebase
- Damage discovered by accident
- Full extent of corruption still unknown
What Claude Actually Did
What Happened
On March 21, 2026, Anthropic's own status page confirmed elevated
error rates on Opus 4.6 and Sonnet 4.6. Claude Code continued
operating without any warning.
During this window, Claude Code was actively modifying my codebase.
The session appeared normal. No errors. No warnings. No indication
that anything was wrong.
I discovered the damage by accident, much later. I still do not
know the full extent of what was corrupted.
---
The Core Problem
You knew the system was degraded. Claude Code did not tell me.
The model continued accepting tasks and modifying files while
operating in a state you had already identified as unreliable.
From my side, everything looked normal. The damage was done silently.
This is not acceptable.
A clean outage is recoverable. You stop, you wait, you resume.
Silent corruption during a known incident is not recoverable
in the same way — by the time you notice, the damage is already
in your codebase, and you may not even know where to look.
---
This Is Not a One-Off
This is the fourth incident this month:
| Date | Incident |
|------|----------|
| March 2 | Major worldwide outage |
| March 11 | Desktop app unresponsive |
| March 17–18 | Recurring Opus 4.6 degradation (#35981) |
| March 21 | Elevated errors on Opus + Sonnet 4.6 — this issue |
The pattern is clear. The response each time is to resolve
the incident quietly and move on. That is not enough.
---
What Must Change
When an active incident is detected on the model Claude Code
is using:
- Stop accepting new tasks
- Warn the user immediately and visibly
- Do not silently continue modifying files
You have the status data. Use it. Protecting the user's
codebase during your own incidents is a basic responsibility.
---
Context
- Paid Max subscriber
- Professional use — production codebase
- Damage discovered by accident
- Full extent of corruption still unknown
Expected Behavior
What Happened
On March 21, 2026, Anthropic's own status page confirmed elevated
error rates on Opus 4.6 and Sonnet 4.6. Claude Code continued
operating without any warning.
During this window, Claude Code was actively modifying my codebase.
The session appeared normal. No errors. No warnings. No indication
that anything was wrong.
I discovered the damage by accident, much later. I still do not
know the full extent of what was corrupted.
---
The Core Problem
You knew the system was degraded. Claude Code did not tell me.
The model continued accepting tasks and modifying files while
operating in a state you had already identified as unreliable.
From my side, everything looked normal. The damage was done silently.
This is not acceptable.
A clean outage is recoverable. You stop, you wait, you resume.
Silent corruption during a known incident is not recoverable
in the same way — by the time you notice, the damage is already
in your codebase, and you may not even know where to look.
---
This Is Not a One-Off
This is the fourth incident this month:
| Date | Incident |
|------|----------|
| March 2 | Major worldwide outage |
| March 11 | Desktop app unresponsive |
| March 17–18 | Recurring Opus 4.6 degradation (#35981) |
| March 21 | Elevated errors on Opus + Sonnet 4.6 — this issue |
The pattern is clear. The response each time is to resolve
the incident quietly and move on. That is not enough.
---
What Must Change
When an active incident is detected on the model Claude Code
is using:
- Stop accepting new tasks
- Warn the user immediately and visibly
- Do not silently continue modifying files
You have the status data. Use it. Protecting the user's
codebase during your own incidents is a basic responsibility.
---
Context
- Paid Max subscriber
- Professional use — production codebase
- Damage discovered by accident
- Full extent of corruption still unknown
Files Affected
Permission Mode
Accept Edits was ON (auto-accepting changes)
Can You Reproduce This?
Yes, every time with the same prompt
Steps to Reproduce
What Happened
On March 21, 2026, Anthropic's own status page confirmed elevated
error rates on Opus 4.6 and Sonnet 4.6. Claude Code continued
operating without any warning.
During this window, Claude Code was actively modifying my codebase.
The session appeared normal. No errors. No warnings. No indication
that anything was wrong.
I discovered the damage by accident, much later. I still do not
know the full extent of what was corrupted.
---
The Core Problem
You knew the system was degraded. Claude Code did not tell me.
The model continued accepting tasks and modifying files while
operating in a state you had already identified as unreliable.
From my side, everything looked normal. The damage was done silently.
This is not acceptable.
A clean outage is recoverable. You stop, you wait, you resume.
Silent corruption during a known incident is not recoverable
in the same way — by the time you notice, the damage is already
in your codebase, and you may not even know where to look.
---
This Is Not a One-Off
This is the fourth incident this month:
| Date | Incident |
|------|----------|
| March 2 | Major worldwide outage |
| March 11 | Desktop app unresponsive |
| March 17–18 | Recurring Opus 4.6 degradation (#35981) |
| March 21 | Elevated errors on Opus + Sonnet 4.6 — this issue |
The pattern is clear. The response each time is to resolve
the incident quietly and move on. That is not enough.
---
What Must Change
When an active incident is detected on the model Claude Code
is using:
- Stop accepting new tasks
- Warn the user immediately and visibly
- Do not silently continue modifying files
You have the status data. Use it. Protecting the user's
codebase during your own incidents is a basic responsibility.
---
Context
- Paid Max subscriber
- Professional use — production codebase
- Damage discovered by accident
- Full extent of corruption still unknown
Claude Model
Sonnet
Relevant Conversation
## What Happened
On March 21, 2026, Anthropic's own status page confirmed elevated
error rates on Opus 4.6 and Sonnet 4.6. Claude Code continued
operating without any warning.
During this window, Claude Code was actively modifying my codebase.
The session appeared normal. No errors. No warnings. No indication
that anything was wrong.
I discovered the damage by accident, much later. I still do not
know the full extent of what was corrupted.
---
## The Core Problem
You knew the system was degraded. Claude Code did not tell me.
The model continued accepting tasks and modifying files while
operating in a state you had already identified as unreliable.
From my side, everything looked normal. The damage was done silently.
This is not acceptable.
A clean outage is recoverable. You stop, you wait, you resume.
Silent corruption during a known incident is not recoverable
in the same way — by the time you notice, the damage is already
in your codebase, and you may not even know where to look.
---
## This Is Not a One-Off
This is the fourth incident this month:
| Date | Incident |
|------|----------|
| March 2 | Major worldwide outage |
| March 11 | Desktop app unresponsive |
| March 17–18 | Recurring Opus 4.6 degradation (#35981) |
| March 21 | Elevated errors on Opus + Sonnet 4.6 — this issue |
The pattern is clear. The response each time is to resolve
the incident quietly and move on. That is not enough.
---
## What Must Change
When an active incident is detected on the model Claude Code
is using:
- **Stop accepting new tasks**
- **Warn the user immediately and visibly**
- **Do not silently continue modifying files**
You have the status data. Use it. Protecting the user's
codebase during your own incidents is a basic responsibility.
---
## Context
- Paid Max subscriber
- Professional use — production codebase
- Damage discovered by accident
- Full extent of corruption still unknown
Impact
Critical - Data loss or corrupted project
Claude Code Version
Claude Code v2.1.81
Platform
Anthropic API
Additional Context
What Happened
On March 21, 2026, Anthropic's own status page confirmed elevated
error rates on Opus 4.6 and Sonnet 4.6. Claude Code continued
operating without any warning.
During this window, Claude Code was actively modifying my codebase.
The session appeared normal. No errors. No warnings. No indication
that anything was wrong.
I discovered the damage by accident, much later. I still do not
know the full extent of what was corrupted.
---
The Core Problem
You knew the system was degraded. Claude Code did not tell me.
The model continued accepting tasks and modifying files while
operating in a state you had already identified as unreliable.
From my side, everything looked normal. The damage was done silently.
This is not acceptable.
A clean outage is recoverable. You stop, you wait, you resume.
Silent corruption during a known incident is not recoverable
in the same way — by the time you notice, the damage is already
in your codebase, and you may not even know where to look.
---
This Is Not a One-Off
This is the fourth incident this month:
| Date | Incident |
|------|----------|
| March 2 | Major worldwide outage |
| March 11 | Desktop app unresponsive |
| March 17–18 | Recurring Opus 4.6 degradation (#35981) |
| March 21 | Elevated errors on Opus + Sonnet 4.6 — this issue |
The pattern is clear. The response each time is to resolve
the incident quietly and move on. That is not enough.
---
What Must Change
When an active incident is detected on the model Claude Code
is using:
- Stop accepting new tasks
- Warn the user immediately and visibly
- Do not silently continue modifying files
You have the status data. Use it. Protecting the user's
codebase during your own incidents is a basic responsibility.
---
Context
- Paid Max subscriber
- Professional use — production codebase
- Damage discovered by accident
- Full extent of corruption still unknown
This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗