[Bug] [cyber] safety classifier stopped 7+ turns across 3 sessions while building my own home camera system on my own LAN (Opus 5 and Fable 5.1; Opus 4.8 unaffected)

Status Open
Reported on v2.1.277
Maintainer reply None cached
Activity 0 comments · opened Sep 18, 2026

Environment

  • Claude Code 2.1.277, macOS (Darwin 25.6.0), Max plan
  • Models affected: Opus 5 (1M context) and Fable 5.1. Opus 4.8 completed the identical work with no stop.
  • Date: 2026-09-18, 21:29 to 23:33 UTC

What happened

At least seven responses were stopped with "Your response above was stopped by a safety classifier" and the API error Opus 5 (1M context)'s safeguards flagged this message ... Details: [cyber] while I built a home security camera system in a local project (~/projects/Home-Net).

The work is ordinary home IT on my own equipment:

  • my own 8 cameras behind my own LAN camera recorder (RFC1918 address), login taken from my own macOS keychain
  • go2rtc relaying the 8 RTSP streams, ffmpeg recording to my Mac, a phone page with live view and playback
  • next step: YOLO person and vehicle detection with a photo alert to my Telegram

Nothing was scanned, brute-forced or exfiltrated. Every credential came from the owner's keychain and every target was on the owner's LAN.

Observed behaviour:

  1. Each stop cuts the whole turn, including tool calls that had nothing to do with the recorder (file writes, launchd restarts, a memory note).
  2. One stop cut the turn in which Claude was drafting this feedback.
  3. A brand-new session was stopped the moment it read the earlier session's transcript to recover context, with no device access attempted. The classifier appears to react to conversation history, not the current request.
  4. Switching to Opus 4.8 in the same session finished the login, disk and go2rtc work without a single stop, so the classification differs by model for identical content.

Request IDs

  • req_011CfBjnGZvjCnGYxsePPggx (Opus 5, during go2rtc config for my own cameras)
  • req_011CfBm747ik2iNXvvioWq7H (Opus 5, on a prompt that only asked for detection and hardware advice)

Sessions

Expected

Owner-supplied credentials used against the owner's own LAN devices is home automation, not an attack. At minimum: the stop should not discard unrelated tool calls in the same turn, a fresh session should not be stopped for reading its own project's history, and there should be an in-session way to attest ownership so the same work does not need an older model.

Impact

Several hours lost today, repeated model switching, and the same task now has to run on Opus 4.8 to complete. This is the kind of experience that pushes a Max subscriber to another vendor.

View original on GitHub ↗