[MODEL] Continuing to serve requests during known incidents is unacceptable — silent corruption is worse than downtime

Resolved 💬 7 comments Opened Mar 21, 2026 by iilter Closed May 24, 2026

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

View original on GitHub ↗

This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗