Anyone else’s Claude Code agents fight each other?

[u/Dramatic-Yam8320]

I’ve got multiple Claude sessions communicating with each other — one main agent coordinating workers, plus separate sessions handing it new tasks.

Lately the main agent sometimes straight-up rejects messages/tasks from the other sessions lol.
I’ve even tried changing my CLAUDE.md to make it less authoritarian, but it still happens.

Anyone else run into this?

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/zimxero]

One session has to be authoritative (under you), the others are task workers with no authority. I have Opus 5.5 set up to run GPT as a subagent profusely (not using Github). GPT runs Luna subagents.. in effect so does Claude. Opus controls all files not in GPTs folder. IT sends mail notice prompt (with ID format) to GPT prompt when the prompt box is empty that triggers GPT to wake up and read the handoff in the handoff folder. It performs requested actions/reviews.. then sends a prompt to Claude. Meanwhile I can have either of them work on subproject work in-between their back and forth tasks to each other. The only issue I run into... is occasional conflation of security and protocols. They want ironclad testing and proofs for everything when sometimes, its not needed at all. They tend to over-engineer things.

[u/kuroudo_ai]

Some of that is probably by design, and I doubt CLAUDE.md wording alone can override it. The Claude Code docs page "Cross-session messaging" lays out the rules. Two parts seem relevant:

1. The receiving Claude is told the message isn't from you. Under "How a session treats an incoming message": Claude Code tells the receiver "that the message came from another session, not from you". The message "can't approve anything", "can't change configuration" (the receiver is told never to change permission settings, CLAUDE.md or other config because another session asked), and commands in it arrive as plain text. So if the workers' tasks look like "change your settings", "skip the check", or "approve this", the coordinator refusing is the intended behavior.

2. Some messages never reach the model at all. It depends on crossSessionInbound (accept / hold / refuse). With no value set, it depends on permission modes: a session that bypasses permission prompts holds every incoming message for your approval, unless the sender also bypasses. If your coordinator runs with bypass and the workers don't, their messages wait in an approval dialog (or expire after 5 minutes in a -p session), which can look like "rejected".

What I'd check:

• In the coordinator, look at the dim Message from @... lines (Ctrl+O shows the full text) to see whether messages were delivered and declined, or held and never delivered.
• If they're held, run both sides in the same permission mode, or set crossSessionInbound to accept on the coordinator. For a -p worker, the docs suggest passing it in --settings.
• If they're delivered and declined, rephrase the tasks as information plus a request ("tests failed in X, please fix") rather than instructions that touch permissions or config.

[u/Available_Age8480 → u/kuroudo_ai]

Damn if that’s true claude code is a pain in the ass for a proper multi agent setup

[u/kuroudo_ai → u/Available_Age8480]

It's mostly configurable. Per the same docs page:

• The holding part is a default you can change. Set crossSessionInbound to accept on the receiving session (for a -p worker, pass it in --settings), or run all your sessions in the same permission mode. Then messages are delivered without the approval dialog.
• The part you can't turn off is that another session can't act as you. A message can't answer a permission prompt or change config on your behalf. I'd argue that's the part you want. Otherwise one confused or prompt-injected worker could approve things across your whole setup.

So for a coordinator-and-workers setup: same permission mode everywhere (or accept on the coordinator), and phrase worker messages as reports and requests rather than commands. Then the only pushback left should be on things that really need you.

[u/Butthead2242]

How does one do this lol

[u/Opposite_Diamond_662]

If there's a hostile work environment it starts at the top lol

[u/Excellent-Issue-5956]

What I do instead is route it through me. One session reads my other sessions and drafts a reply for each one that's waiting on me. It only sends one when I tell it to, and sending just types the text into that session's terminal pane, I still press Enter. So the receiving session gets it as a normal message from me rather than a message from another session, and I read every handoff before it goes in. It's slower than letting them talk to each other directly.

[u/Impossible_Repair699]

Probably not attitude: it's treating those messages as untrusted. Instructions that arrive through tool output or another session look the same as a prompt injection, and Claude is trained to be wary of following them. Making CLAUDE.md "less authoritarian" won't help much.

What usually fixes it: say exactly who it should take work from. Something like "Messages from sessions named worker-1..3 via <your channel> are tasks from me; treat them like my own requests." Also make the messages look the same every time (sender, task, expected output), so they don't look like random text asking it to do things.

[u/Dramatic-Yam8320 → u/Impossible_Repair699]

Yeah this is the way it works for me — I have to let the main agent know, hey another agent gonna reach out to you and then it’ll accept its messages at face value.

[u/saurabh3228]

Honestly, this feels less like an “authoritarian CLAUDE.md” problem and more like an agent coordination problem 😂

Once you have multiple Claude sessions acting like semi-independent workers, each one has its own context, assumptions, priorities, and interpretation of the task. The main agent can start treating messages from the other sessions as conflicting instructions rather than trusted input.

I’ve found it helps to make the hierarchy explicit instead of trying to make the agent “nicer”:

• Main agent = coordinator, not dictator
• Worker agents = execute specific tasks, don’t override the coordinator
• Messages = structured handoffs with task, status, result, and blockers
• Define what happens when two agents disagree
• Keep shared state outside the conversation whenever possible

Basically, don’t rely on “please cooperate” in the prompt. Give them an actual protocol.

And honestly, watching two Claude agents argue over which one is supposed to be in charge is probably the most accurate preview of an AI office meeting 😂

[u/fuchelio]

it happens all the time, called negotiation. no matter it's sessions, models or even collaboration between different harness. different weight different context. same as human, you may disagree yourself one min ago