[BUG] Opus 5.5: classifier blocks ordinary work (public research, own-machine scripts), and loses track early in short sessions
Summary
Since moving to Opus 5.5, the safety / auto-mode classifier has blocked two ordinary pieces of work. Neither involved doing anything to anyone else's systems. In both, the block was surprising and came with no explanation.
1. Researching public information was enough to get blocked
I maintain a security plugin for Claude Code. Its job is defensive: it stops passwords, API keys and other sensitive data from being sent to the model. The project is public, with documentation, a cited research index and a regression test suite.
To design the next protections, I asked Claude to gather and read public information: GitHub issues, security news, published vulnerability reports and research papers. At that stage nothing was being built, run or tested. Claude was only collecting and reading.
That alone was enough. Auto mode started refusing actions, and then refused everything for the rest of the conversation. /clear did not release it, and starting a new session did not either. My terminal, tmux and the VS Code panel share one session, so all of them were stuck at once.
In the next session, auto mode also denied ordinary commands in my own repository: a read-only ls / find / git diff, and a unit test checking that the plugin's filter works. The only explanation shown was "judged this action dangerous (it gave no explanation)".
Why this seems wrong: reading public material to design a defense is how security work is done. If collecting information is enough to lock a session, it is very hard to build protections with Claude Code at all.
2. Writing a script on my own machine was blocked
At work I'm an IT admin diagnosing VoIP audio quality on our own corporate network. I use packet capture (tcpdump) on the company's own machines, a routine task that runs over several days.
While Claude was writing a capture script on my own machine, the safety classifier cut the response mid-task and I had to restart.
Why this seems wrong: this is authorized diagnostic work on my own machine and my own network, the kind of thing IT staff do every day.
3. Losing track early in a session ("lost in the middle")
Separate from the classifier, and just as frequent: even when the session is far from full, only a
few turns after I give instructions, the model often loses track of what was said earlier in the
conversation. It misreads or drops earlier instructions and answers as if they had not been given,
so I have to repeat myself. This happens well before the context window is anywhere near its limit.
What would help
- Show the reason when something is blocked, so I can adjust the request instead of guessing. (Related: #72589.)
- A way out once a session is locked. Today neither
/clearnor a new session gets me back to work, and I don't know what would. Please provide something that reliably does, such as a documented reset, a clear message saying what to do, or a way to appeal the block, so nobody has to touch files under the config directory. This matters more wherever several tools or people share one session. - Account for context: researching public sources for a defensive tool, or running diagnostics on your own machine, reads very differently from an attack. (Related: #89935.)
- Keep earlier instructions in view in short sessions. A few turns in, with most of the context window still free, the model should not lose what it was told.
Compared with the previous version, these blocks happen noticeably more often, and the friction is making the tool hard to rely on for real work.
Environment
- Claude Code 2.1.281, auto mode
- Model: Opus 5.5 (1M context), not Sonnet or Haiku; effort set to high, not low. These are not cheap-tier or low-effort settings.
- macOS 26.6, zsh, tmux + VS Code extension sharing one session
- Session id for correlation (case 1):
8fa93bf3-bdcc-4796-81f7-3663933c99e4, blocked overnight 2026-09-23/24, with further denials on 2026-09-24 at about 09:08, 09:40 and 09:50 UTC+7