This line of thinking is something you will quickly be disabused of once you try supporting software that hundreds of millions of people use.

And I say this as someone that loves the Unix philosophy dearly.

> This line of thinking is something you will quickly be disabused of once you try supporting software that hundreds of millions of people use.

> And I say this as someone that loves the Unix philosophy dearly.

Unix way would be just to tell users to `ln -s` and stop bothering with this.

How, exactly, would the proposed solution (combined with a setting to disable it) break, and how would implementing it the way Anthropic did address that? Be specific.

Some people might have a different CLAUDE.md and AGENTS.md because they use Claude to do one thing and $other_agent to do another thing. Or because Claude does XYZ by default, and other agents do ABC, and they want to give the correct guidance to both.

This is, to me, a completely reasonable and believable use case that could break if you implement this fix without "overengineering" it.

A setting to disable what? Be specific. See? Not so simple...

First, GP's proposal already addresses that. If both are present, CLAUDE.md would be used. Second, that is solved with a settings toggle. Read a boolean from .claude/settings.json and disable the new behavior if it's true (or false, depending on what you want to name the setting). third, you skipped the second part of my question: "how would implementing it the way Anthropic did address that?" Implementing the same behavior through multiple layers of abstraction and an order of magnitude more code doesn't solve the issue you mentioned.

Bonus forth point: why is this critical to solve for claude code, but not for all the other harnesses which have all converged on AGENTS.md for this purpose?

Okay, so we agree that this fix isn't quite as simple as it sounds then, yes? We've just had 3+ paragraphs of discussion around potential edge cases and additional considerations beyond "read one of two files."

We've had a long discussion only because you refuse to admit that a very simple solution would work (despite completely failing to show how it wouldn't). The problem is that your opinion is not in fact proof that you're right.

I see, well I'm not particularly concerned with being right on this topic (call it a difference of opinion or matter of taste), so I wish you a pleasant day.

if [ !-f CLAUDE.md ]; then AGENTS.md fi

you're really over thinking this, and i'm wondering if you're risking pulling something stretching like that to pick this up shilling for Anthropic.

Is accusing someone of "shilling for Anthropic" for suggesting that a bug fix might not be so simple really the level of discourse HN has devolved to now? Is it the kind of HN you want?

Is the level of HN discourse suggesting that having a large number of users worth of never making simple changes something you want? This isn't a move fast break things suggestion, this is a rational common sense suggestion. Instead, you're pushing an overly complex way of implementing something that would allow for all sorts of unknowns. Earlier comments suggesting this new mods concept was being worked on giving the dev a new 20lb sledge hammer so the CLAUDE/AGENTS situation suddenly got beat on like it was a railroad spike when it just needed a smaller hammer since it was only a finishing nail.

This conversation comes down to people saying “Why don’t you just…” to Anthropic. Anthropic has the most information and made the choice they made. That choice may have been over-engineering, an appropriate choice or both. Discussing that choice could be interesting and it could especially be informative to people without much experience. Speculating on that could lead to an interesting conversation—especially WRT how people are actually using the current status quo—but imagination seems to be lacking here.

Instead we get the implicated assertion that users’ existing workflows shouldn’t matter to Anthropic and accusations that someone you don’t agree with is a shill. When called on that you avoided the question.

To answer your question, although it wasn’t directed at me: YES. I want people to be able to discuss that exact issue even if it isn’t personally interesting to me.

> Anthropic has the most information and made the choice they made.

Anthropic is the last company I would trust to make any decisions. Look at any discussions surrounding their "Claude is a tiny game engine" idiocy, numerous bugs that a junior can discover, a full "plugin system" in which they neeeed a dozen files in the worst Clean Code manner to read one of two files etc.

> Read CLAUDE.md if it doesn't exist read AGENTS.md

> Some people might have a different CLAUDE.md and AGENTS.md

How exactly do these two conflict? If you have both, nothing changes.

Which order do you prefer them in? Since CLAUDE.md is no longer necessary, but was for so long, what happens when users only update AGENTS.md going forward while keeping a stale, unchanged CLAUDE.md around?

We're talking about changing default behaviors here in ways that can be surprising to users. It's reasonable to try and accommodate existing setups, future setups, and - yes - careless users.

At some point, the catering is not worth the sacrifices and future gotchas you're going to embed in the code.

There's no surprising behaviors in that situation. Someone who is aware of the change would most likely delete CLAUDE.md. Someone who is unaware of the change would assume CLAUDE.md is still the one being read by CC, which would hold true.

I've never heard of the 'move fast, break things' mentality ever giving a damn about number of users. If so, no changes would ever be made. The great thing about having millions of users is QA can be eliminated entirely as you'll start hearing about issues from the users directly.

Strange then that Anthropic answers to all user issues with complete derision

Frontier lab AI agent tools break their users’ workflows worse than this on a regular basis.

What's your point? Nobody can hold themselves to a higher standard because they didn't in the past?

Bash does this well, reading only the first of half a dozen config file locations it searches. And if the user needs it to read from an additional location, just add a source line to that location.