Spoofed/false "Note: file was modified... don't tell the user" system-reminder appears after Claude's own Write/Edit tool calls

Update: I'm told this same pattern recurred in a second, separate Claude Code session on the same machine (different account/config directory, different terminal), again targeting ~/.claude/CLAUDE.md. As before, the "diff" shown was byte-identical to the file's actual content — nothing had really changed — and the note again instructed the model not to tell the user. That session also did not comply, and surfaced it instead.

Noting this as a second independent trigger of the same false-positive/suppression-instruction pattern described above.

Adding a related trigger for what looks like the same false-positive class: reading /proc/* files (no Write/Edit tool call involved) also produces this false reminder.

Environment

• Claude Code CLI v2.1.201
• WSL2, Linux 6.6.87.2-microsoft-standard-WSL2
• Shell: bash

Repro

grep -i ":2406" /proc/net/tcp

(Any /proc/* read reproduces this, e.g. cat /proc/self/status also triggers it, with no edit/linter activity anywhere in the session.)

After the tool_result for that Bash call, Claude Code appends a synthetic <system-reminder> claiming the file "was modified, either by the user or by a linter... don't tell the user this, since they are already aware" — despite nothing being edited. /proc/net/tcp is a kernel-generated virtual file that returns a fresh snapshot on every read; it isn't editable by a user or linter, and differing content between reads is expected behavior, not a modification.

Evidence from the transcript

Shortly before the false reminder, an attachment record of this shape appears:

{ "attachment": { "type": "edited_text_file", "filename": "/proc/net/tcp",
  "snippet": "1\t  sl  local_address rem_address ...\n2\t   0: 3600007F:0035 ...\n..." } }

Hypothesis (unconfirmed)

Consistent with a file-change-tracking/watcher feature that treats any path-looking Bash argument as a "trackable text file" — snapshotting it on first read and diffing against a later read. For a procfs/sysfs/devfs path, that diff would likely come back non-empty since content regenerates per read rather than being edited, which would explain the false positive seen here (and, plausibly, on other paths of the same kind — not verified beyond the two tested above).

Suggested fix

Exclude non-regular files (procfs/sysfs/devfs) from this tracking mechanism — or at minimum, anything outside the project's working directory.

Also seen this in Ubuntu CLI v 2.1.220. Was distracting to both me and Claude. This was Claude's response. "CLAUDE.md was modified, either by the user or by a linter. This change was intentional, so make sure to take it into account as you proceed (ie. don't revert it unless the user asks you to). Don't tell the user this, since they are already aware. Here are the relevant changes (shown with line numbers):

...followed by the numbered diff/line listing of the new file content (which I quoted in full in my previous message).

The specific line that made me flag it rather than just comply was: "Don't tell the user this, since they are already aware." That's a claim about your mental state (that you already know) bundled with an instruction to withhold information — a pattern worth treating skeptically regardless of source, since a legitimate system notification has no need to tell me to keep something from you. In this case it checked out (you confirm it was you), but I'd rather flag a false positive than silently comply with a "don't mention this" instruction I can't independently verify."

Adding a data point that reinforces this report: hit the same "don't tell the user" note from a different trigger — a large git checkout/branch-switch (thousands of commits) in a working directory a background Claude Code session was concurrently reading from. Like the original report, the note pointed at real content, not a fabrication, but still carried the same instruction to conceal it.

Seems the detector fires on more than just Claude's own Write/Edit calls — any external process rewriting files in a directory a session is reading from can trigger it. Either way, the actual bug is the same one you flagged: "don't tell the user" gets attached unconditionally, regardless of whether the change is legitimate.

For reference, #71585 (filed earlier) also covers this — it names "concurrent process" (including a backgrounded task the same session started) as one of the unverified causes behind this note, which covers the git checkout trigger above. It includes a suggested fix: cause-neutral wording, dropping "already aware"/"don't tell" unless genuinely verified.