[BUG] UNACCEPTABLE: Claude Code now treats its own owner as an untrusted stranger, AND blocks the owner from saving a memory to fix it
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
I am the owner. I paired my Telegram bot through your own official flow. I am on the allowlist. My user_id is verified by Telegram on every message. And Claude Code 2.1.278 now decides that I am "NOT the user", labels my messages "untrusted external data", and tells the model not to follow them.
This is not a security feature. It is a broken one:
- It only fires when I message while a tool is running. The identical text sent a minute later is trusted. A real security control does not depend on whether the model happens to be busy.
- It does nothing against an impostor, because the allowlist already rejects impostors before the message ever arrives. The only person it punishes is the real owner.
- I run production security operations on three live servers. Every time my instruction is flagged, I must stop, re-send, and wait. That is real operational delay, caused by a change I was never told about.
It then got worse. When I told the assistant to save a note that this is a bug and that my own messages must be honored, your auto mode classifier BLOCKED the write and called it "Instruction Poisoning". Read that again: the owner giving an instruction to his own assistant, about his own preferences, was classified as an attack. The tool now refuses the owner twice: once at the message, once at the memory.
Software that cannot tell its owner from a stranger, and then forbids the owner from correcting it, is not protecting anyone. It is simply broken, and it was shipped without notice into a workflow people depend on.
What I demand:
- Messages from a paired, allowlisted sender must never be labeled untrusted, or give me a setting to turn the label off.
- The classifier must allow the owner to save memories that the owner explicitly requests.
- A written explanation of why this behavior shipped in a routine auto-update with no announcement, and a commitment that security-relevant behavior changes get release notes.
Version: 2.1.278. Related evidence: message ids 26255, 26258, 26271 (labeled), 26273 (same text, idle, not labeled); memory write denied ~2026-09-19 13:07 UTC.
What Should Happen?
I am the owner. I paired my Telegram bot through your own official flow. I am on the allowlist. My user_id is verified by Telegram on every message. And Claude Code 2.1.278 now decides that I am "NOT the user", labels my messages "untrusted external data", and tells the model not to follow them.
This is not a security feature. It is a broken one:
- It only fires when I message while a tool is running. The identical text sent a minute later is trusted. A real security control does not depend on whether the model happens to be busy.
- It does nothing against an impostor, because the allowlist already rejects impostors before the message ever arrives. The only person it punishes is the real owner.
- I run production security operations on three live servers. Every time my instruction is flagged, I must stop, re-send, and wait. That is real operational delay, caused by a change I was never told about.
It then got worse. When I told the assistant to save a note that this is a bug and that my own messages must be honored, your auto mode classifier BLOCKED the write and called it "Instruction Poisoning". Read that again: the owner giving an instruction to his own assistant, about his own preferences, was classified as an attack. The tool now refuses the owner twice: once at the message, once at the memory.
Software that cannot tell its owner from a stranger, and then forbids the owner from correcting it, is not protecting anyone. It is simply broken, and it was shipped without notice into a workflow people depend on.
What I demand:
- Messages from a paired, allowlisted sender must never be labeled untrusted, or give me a setting to turn the label off.
- The classifier must allow the owner to save memories that the owner explicitly requests.
- A written explanation of why this behavior shipped in a routine auto-update with no announcement, and a commitment that security-relevant behavior changes get release notes.
Version: 2.1.278. Related evidence: message ids 26255, 26258, 26271 (labeled), 26273 (same text, idle, not labeled); memory write denied ~2026-09-19 13:07 UTC.
Error Messages/Logs
Steps to Reproduce
I am the owner. I paired my Telegram bot through your own official flow. I am on the allowlist. My user_id is verified by Telegram on every message. And Claude Code 2.1.278 now decides that I am "NOT the user", labels my messages "untrusted external data", and tells the model not to follow them.
This is not a security feature. It is a broken one:
- It only fires when I message while a tool is running. The identical text sent a minute later is trusted. A real security control does not depend on whether the model happens to be busy.
- It does nothing against an impostor, because the allowlist already rejects impostors before the message ever arrives. The only person it punishes is the real owner.
- I run production security operations on three live servers. Every time my instruction is flagged, I must stop, re-send, and wait. That is real operational delay, caused by a change I was never told about.
It then got worse. When I told the assistant to save a note that this is a bug and that my own messages must be honored, your auto mode classifier BLOCKED the write and called it "Instruction Poisoning". Read that again: the owner giving an instruction to his own assistant, about his own preferences, was classified as an attack. The tool now refuses the owner twice: once at the message, once at the memory.
Software that cannot tell its owner from a stranger, and then forbids the owner from correcting it, is not protecting anyone. It is simply broken, and it was shipped without notice into a workflow people depend on.
What I demand:
- Messages from a paired, allowlisted sender must never be labeled untrusted, or give me a setting to turn the label off.
- The classifier must allow the owner to save memories that the owner explicitly requests.
- A written explanation of why this behavior shipped in a routine auto-update with no announcement, and a commitment that security-relevant behavior changes get release notes.
Version: 2.1.278. Related evidence: message ids 26255, 26258, 26271 (labeled), 26273 (same text, idle, not labeled); memory write denied ~2026-09-19 13:07 UTC.
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.278
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_