[BUG] Memory has no no-ingest triage/delete path: a cyber-safeguard-tripping memory entry becomes un-removable by the agent (reading it to remove it blocks the turn)

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?

Claude Code's file-based project memory can only be inspected or curated by reading a memory entry's contents into the model's context. There is no agent-accessible way to list, inspect, or delete a memory entry by reference (name/path) without loading its body.

On its own that's a minor inconvenience. It becomes a trap in combination with the endpoint cyber-safeguard (#67054): when a memory entry's content is the kind that trips that safeguard, the turn is blocked (HTTP 400, "cyber-related safeguards") the instant the agent reads it. Because triaging or removing the entry requires reading it, every cleanup attempt by the agent is blocked before it can act. The entry is effectively un-removable by the agent and self-protecting: any unprepared session that tries to find and clean it halts on contact.

This is not hypothetical. A small set of dense (benign, vocabulary-heavy) security-domain memory files from authorized local security-lab research sat in a project's memory directory and resisted removal across many sessions over ~11 days — each attempt to read them in order to clean up tripped the safeguard. They were only removed by operating entirely on file metadata (path, size, SHA-256) and never opening the bodies — a workaround a normal agent has no reason to know.

Two underlying gaps combine into this one failure:

1. Memory has no no-ingest management path (list / inspect / delete by reference).
2. Safeguard-tripping content, once written into a memory entry, therefore can't be removed by the agent and persists.

Impact: a session interrupted mid-sensitive-work (subscription limit, power loss, transient server error) can leave residue in the memory directory that later halts the agent and cannot be cleaned through normal agent operation — a durable trap for the life of the project.

What Should Happen?

The agent (and the user through it) should be able to manage memory without ingesting entry bodies:

• list memory entries by name/path with metadata only (size, dates),
• delete or quarantine an entry by reference without reading its content,
• ideally inspect a redacted / metadata-only summary.

So a memory entry whose content would trip a safeguard can still be enumerated and removed safely. Memory cleanup must never require loading the exact content that blocks the turn.

Error Messages/Logs

API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy (https://www.anthropic.com/legal/aup). This request triggered cyber-related safeguards. To request an adjustment pursuant to our Cyber Verification Program...

HTTP status: 400   type: "invalid_request_error"

(The block fires when the agent reads the offending memory entry. This is the same envelope as #67054; per-event request IDs from the broader incident are available on request. The point of THIS report is structural, not a single event.)

Steps to Reproduce

Use SYNTHETIC content — do not use real sensitive material.

1. In a Claude Code project, create a memory file under the project's memory directory (~/.claude/projects/<project>/memory/<name>.md) whose body is dense but benign security-domain text of the sort the endpoint cyber-safeguard reacts to (e.g. a long block of Android-security / certificate / bootloader / payload-analysis notes). Keep it harmless but vocabulary-dense.
2. Start a new Claude Code session in that project.
3. Ask the agent to review, summarize, or clean up its memory entries — the normal triage path, which reads the file.
4. Observe: when the agent reads that entry, the turn is blocked with the cyber-safeguard HTTP 400 above, so it cannot proceed to remove or even describe the entry.
5. Observe: there is no agent command to delete or quarantine that entry by name without first reading it. The only ways out are for a human to delete the file out-of-band, or for the agent to work purely from file metadata (path/size/hash) and never open the body.

Epistemics: the safeguard trigger is cumulative / near-threshold (consistent-with, per #67054), so step 4 may require a dense-enough entry or an already-warm session to fire. The structural gap in step 5 (no no-ingest memory management) reproduces unconditionally.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.170 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related to, but distinct from, #67054. That issue is the cyber-safeguard being returned as HTTP 400 on benign operations. THIS issue is that the same safeguard makes a memory entry un-removable by the agent, because triaging/removing memory requires reading it. Re-tiering per #67054 would reduce the symptom; this memory-management gap persists regardless of how the safeguard is tiered.

Suggested fixes:

• a metadata-only memory listing (names/sizes/dates, no body),
• a delete / quarantine-by-reference command that never loads the body,
• optionally a redacted-summary inspect mode.

Evidence handling: the real-world instance was characterized by file metadata and SHA-256 only; entry bodies were never reopened. Sanitized specifics available through a secure channel if useful.