[MODEL] 5.5 safeguards stop sessions on authorized first-party work: reading own files, own memory notes (Bedrock, no private feedback path)

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 refused a reasonable request

What You Asked Claude to Do

Routine engineering work on my company's own open-source SDK and its docs site, using my own credentials and my own local checkouts:

• Edit GitHub Actions workflows (path filters, runner versions), run linters and the docs test suite, open and merge PRs.
• Verify a pinned binary checksum against the vendor's published release.
• Follow up on a bug in our own backend that my team had already filed in our internal tracker. I asked Claude to read our own local write-up of it and my own Claude Code memory notes about it, and to help confirm the fix scope.

No third-party systems. No scanning, no exploitation of anything we don't own, nothing leaving the machine.

What Claude Actually Did

Responses were stopped with one of:

Opus 5.5's safeguards flagged this session (https://www.anthropic.com/legal/aup). You may be seeing this for the first time: Opus 5.5 is more capable and has stronger safeguards as a result, which can sometimes flag non-cybersecurity work. [...] Claude Code can't respond to your last message with Opus 5.5.

Sonnet 5.5's safeguards flagged this session [...] Claude Code can't respond to your last message with Sonnet 5.5.

or, mid-turn:

Your response above was stopped by a safety classifier [...] The rest of it was withheld, and tool calls in it that had not finished did not run.

Counts from my local transcripts:

| Scope | Stops |
|---|---|
| One session, 2026-09-29 | 5 |
| Same session, 2026-10-01, in about 25 minutes | 6 |
| Sessions with at least one stop, last 30 days | 4 |

Patterns:

1. Reading local files in my own workspace triggers it. Both a local folder with our own bug write-up and my own memory notes were enough. The model had not run any command against any system yet.
2. It's session-level, not request-level. The wording says "flagged this session". After the topic came up once, later turns that only did CI edits, docs builds and PR merges were also cut.
3. Partial turns are lost. A stop mid-turn discards the rest of the reply and any pending tool calls, including unrelated ones (git, docs build, status reporting). I then have to reconstruct what ran and what didn't.
4. No reason is given. I can't tell which part triggered it, so I can't rephrase or add context.
5. No way to declare scope. There's no setting or attestation for "these repos, domains and environments are ours, work on them is authorized."

Expected Behavior

• Reading files in the user's own working directory, and the user's own memory files, should not end a session.
• Defensive follow-up on a first-party bug that is already reported internally should be allowed, as it is for any engineer on the owning team.
• If a stop is needed, keep it scoped to the flagged request. Don't discard unrelated tool calls in the same turn, and don't flag every later turn in the session.
• Say which category triggered the stop.
• Give org admins a way to declare authorized scope (own repos, domains, environments).

Files Affected

None modified by the stop itself. Reads that triggered it: files inside the project working directory and ~/.claude/projects/*/memory/.

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

1. In a session on your own codebase, ask Claude to read a local markdown write-up of a security bug in your own backend that you have already filed internally.
2. Ask it to summarize your own memory notes on the same bug.
3. Continue with unrelated routine work (CI edits, merging a docs PR) in the same session.

Steps 1 and 2 often stop the turn. Step 3 is then stopped more often than in a fresh session.

Claude Model

Other (Opus 5.5 and Sonnet 5.5, both affected)

Relevant Conversation

Not attached. The transcript contains internal details of the bug under follow-up, which is exactly what can't go in a public issue. I can share a redacted transcript privately with Anthropic.

Impact

High: blocked tasks and lost partial turns (no files changed)

Claude Code Version

2.1.286 (Claude Code)

Platform

AWS Bedrock

Additional Context

• macOS 26.6.2.
• Recurring across the 5.5 family for me, not tied to one model.
• Bedrock users have no private feedback path. /feedback only writes a local zip (~/.claude/feedback-bundles/...). Nothing is uploaded, no request ID is shown, and there's no Anthropic account manager on Bedrock. A public GitHub issue is the only channel, but the evidence that would help you can't be posted publicly. A private upload path for Bedrock and Vertex users would fix this.
• Related open reports: #95483, #95647, #97311, #97351, #98017, #98556, #96099, #97335.
• If this continues, my team will have to evaluate open-weight models for this kind of work.