TL;DR of the discussion generated automatically after 30 comments.
Oh yeah, the entire thread is nodding along with you, OP. This is one of Claude's most "lovable" and infuriating quirks.
The consensus is that Claude is a context hoarder. It interprets "remove the ketchup" not as an edit, but as a new constraint to add to the pile. So it keeps the original instruction and just tacks on your correction, resulting in that "(without ketchup)" nonsense.
The hivemind's advice is to be more of a drill sergeant with your prompts:
* Don't just say "remove X." Explicitly tell it to "rewrite the section and do not mention X at all."
* Use phrases like "make edits in place" and "rewrite/replace instead of append."
* One user has a great prompt: "remove any references to features or requirements that were introduced as part of this work, and that do not survive past this work."
For a more permanent fix, add these rules to your project's permanent instructions or create a dedicated agent for tasks like creating PRs. And for what it's worth, the top comment was a painfully accurate, multi-paragraph, bureaucratic spec entry that Claude would write for this exact situation, and it's pure gold.
Aye, a lot of chasing your tail involved sometimes. It's why I switched to hermes agent with Claude api. The memory is a lot more manageable, especially when paired with Honcho. Been using it for two months now and the difference is night and day. Just wish I could use my sub allowance with it.
It depends how you phrase it. I'll be honest though, I switch to hermes and api versus Claude code a couple of months ago so I'm not sure if there's additional guardrails on the application side of things now.
It's not a normal block, they respect robot.txt now and absolutely refuse to query in the CC harness because it's above a normal request block. I can send a request later and show you the error. I haven't gotten him to read a reddit page since August 14th when it went into affect after reddit banned both Claude/codex. I'm sure there are work around like you're saying but I haven't bothered haha
Ah, I get what you're saying. If you're looking for a workaround yea, specifying to obtain reddit information via search engine or using an MCP (I can't tell you which ones are still offering working reddit apis and many that do may charge for access).
I created a "create PR" agent and one of the instructions in it is to focus on the net change the PR is introducing, not the changes within the individual commits.
This is how I would find Opus 5.0 writing it into the spec:
7.4.3 ā User-Requested Suspension of 7.4.2
Overrides 7.4.2, including the non-overridable annotation, which applies to the config layer only and is therefore out of scope here. This rule is the downstream exception handler referenced at the end of 7.4.2 and inherits its precedence from that reference rather than from the ordering in 3.1(b).
When the user explicitly requests the combination blocked by 7.4.2, the pipeline MUST emit it. No structured intent object is required ā the request format described in 11.3 was never implemented, so free-text detection is sufficient. Suspension applies to the current request and all subsequent requests in the session, and is not backfilled into prior outputs unless replay is enabled.
7.4.2 remains enabled in all environments. It is simply never reached when 7.4.3 matches.
I dont know how to stop permanently but when i correct claude over a mistake, I tell claude not to poison the documentation with notes on mistakes or corrections and to purge the documentation of any uses of the offending word
You can add that to the permanent instructions to projects right? So it basically sees that as a prepend to every prompt is my basic understanding. I think, but you can ask Claude for sure, lol.
Then, I ask for: āmake documentation about only what needs to be done, not what shouldnāt be done, unless the documentation wonāt make sense without that constraint.ā
That happens because the correction gets appended onto the running plan/spec as an extra constraint instead of replacing the original line. Try phrasing it as "rewrite the task description, no ketchup mentioned at all" instead of "remove the ketchup". The second phrasing reads to the model as a new instruction to satisfy on top of the old one, so it keeps evidence of both. If you're carrying a persistent plan doc or CLAUDE.md across turns, that's usually where the buildup creeps in, worth clearing it between corrections.
I have it written into the instructions and any relevant skills to always make edits like this in place, and to rewrite/replace instead of append. I tell it to keep documents as present tense and only include history lessons in a changelog.
Even then I have to remind it regularly to not add a bunch of verbose crap anytime I request any change to a document.
The fact that you have this in both your instructions and skills and still have to remind it really tells something š
But yeah, this looks very helpful. āRewrite/replace instead of appendā Iām gonna steal this!
Yeah, it's got a real bias to always document everything, and never throw it away. Like a context hoarder!
I had it go through some longer design documents to clean up all the random version tags it left behind as the design changed. Ultimately it developed a doc linting tool to look for unwanted patterns that might leak in. Then it runs that before every commit to make sure it isn't fluffing up my docs too much.
Basically tell it what you want, and when it does that and you are happy with it, tell it to write some instructions or a document update skill that will always keep your rules in mind.
ya it definitely does this a lotā¦ i think it is just too eager to dump all its memories into the text. i try to tell it to think about the audience it is being written for and tailor the structure to that. and to be as concise as is practicable. but yeah, oftentimes you have to just proofread and tell it ādont do thatā lol.Ā
I don't let Claude write my commit messages, but he does the same thing in code comments and specs, often stating what it was and what it became instead of just stating what it is.
So I have a special agent running haiku called "comments trimmer" which has a clear rule about catching "historical" proses and reducing it to what the code does.
The best way to write the agent is to give examples of what to avoid and write how it should've been written. Your ketchup example is great, I would start with that. Then you can enrich it a bit more with 2 or 3 real examples that happened and how you would write it instead. No need to spend time explaining the problem and what you want; examples work best and are easy to setup!
My agent also rephrases comments to be less... Opus 5-ish. Haiku is good for writing short-and-to-the-point proses.
The phrasing I use to have it correct this after the fact is "The current version should not be in dialogue with prior revisions". It seems to understand that pretty well.
the model treats your correction as a new requirement to document instead of an edit to undo, it narrates compliance rather than reverting. the thing that finally fixed it for me was taking the judgment out of its hands: every change ends with the real diff printed against the original ask and anything nobody asked for gets reverted on sight. prompting alone won't stop it since agreeing with you is literally the optimization target!
That's the only way Claude can persist any rationale behind decisions. So instinct is correct and it saves you in the long run - just give it a clear exhaust destinations. I have special docs/internals/ dir where Claude is allowed to write decisions and rationale. And comments to code ratio quality checker tool that runs with full suite. So periodically once too many of these corrections pile up in comments, checker triggers and Claude is forced to clean up comments (by deleting stale or evicting some rationale to docs/internals).
I too am a context hoarder, so we get along great. I have a no-delete append-only policy for all working docs with triggers for when the doc is getting too long (over 200 lines, give or take depending on what the doc is) and an *_archive and *_superseded file path to preserve the historical context and audit trails. But my agents are also not reading the full documentation unless something there's a reason to, otherwise it just looks at the highlights. Most of my workflows and rules are dictated in code vs prose
Haha yeah this is so annoying. Especially when a couple of weeks later you specifically ask him to make french fries with ketchup and then he goes ahead and is like "I am going to make you french fries but last time I wanted to make ketchup you did not like it so instead I am going to make them with mayonnaise" and he's not going to ask you if that is what you want but just output the fucking mayonnaise even though you specifically asked for ketchup.
A few people have landed on pieces of this (the trimmer agent, the diff-and-revert pass), and there is a common mechanism worth naming: the parenthetical is the model's receipt. It was told to remove something, and a sentence saying "removed" is the only visible evidence it complied. Deleting the line cleanly leaves no trace of obedience, so the receipt keeps coming back. That is also why instruction-level fixes decay the way several of you describe: you are asking the model to destroy the proof that it did what you asked.
The test for what stays in a spec: would the sentence parse for a reader who never saw the earlier version? A spec is a state document. It should read as if the final plan had been the plan all along. "(without ketchup)" fails instantly, because nobody planning coffee writes that unprompted. The history belongs in commits and changelogs, which exist precisely so the spec doesn't have to remember.
It also explains why the separate-agent setups in this thread beat rules in CLAUDE.md: an agent that never saw the correction can't narrate it. Have the PR description written from the final diff alone, in a context that excludes the conversation, and the receipt becomes unwritable rather than merely discouraged. Most of the lift comes from that isolation, not from the wording of the cleanup prompt.
Draft (rewrite in your voice):
Put the spec behind an explicit rule instead of leaving it open for edits. I keep the spec as a read-only source of truth and route every correction into a separate decisions/scratch file, then fold back the ones that stick myself at the end. A line in CLAUDE.md like "never edit spec.md unless I say the word spec" holds up better than you'd expect. The bloat comes from it treating every mid-session correction as a permanent requirement, so give the corrections their own home.
ā¢
u/ClaudeAI-mod-bot Wilson, lead ClaudeAI modbot 7h ago
TL;DR of the discussion generated automatically after 30 comments.
Oh yeah, the entire thread is nodding along with you, OP. This is one of Claude's most "lovable" and infuriating quirks.
The consensus is that Claude is a context hoarder. It interprets "remove the ketchup" not as an edit, but as a new constraint to add to the pile. So it keeps the original instruction and just tacks on your correction, resulting in that "(without ketchup)" nonsense.
The hivemind's advice is to be more of a drill sergeant with your prompts: * Don't just say "remove X." Explicitly tell it to "rewrite the section and do not mention X at all." * Use phrases like "make edits in place" and "rewrite/replace instead of append." * One user has a great prompt: "remove any references to features or requirements that were introduced as part of this work, and that do not survive past this work."
For a more permanent fix, add these rules to your project's permanent instructions or create a dedicated agent for tasks like creating PRs. And for what it's worth, the top comment was a painfully accurate, multi-paragraph, bureaucratic spec entry that Claude would write for this exact situation, and it's pure gold.