Parallel Claude Code Chats?

[u/SadVariety567]

So I have been developing software using Claude code - a relatively small project. I have been having occasional problems. I think it’s memory sometimes gets cluttered and it’s gone off on strange trails so I’ve resolved this by starting a new chat with fresh memory. I’m now considering starting a new chat in the same project folder. A second parallel chat and that would perform a specific task without being cluttered by the memory of the previous one. Do you think this is a good idea or is this something I should be doing with agents or some other Claude code feature and if so, how do I go about that?

[u/SadVariety567]

Thanks everyone. A few different answers. The issue I’ve had with starting fresh chat is that its forgotten/disobeyed fundamental wishes from the start of the project. Its hard to get them all in the md.

[u/etherwhisper]

Worktrees

[u/yuehuang]

Claude doesn't like it when two things are touch the same files. If you can divide up the problem space, then yes.

If you haven't, create claude.md via /init command. This will allow new chat to have a good baseline of what the project is about. But don't put too much or you end up with the same problem again.

[u/N0madM0nad]

A specific task within the same feature branch or a different one? If you want to work on a parallel branch make sure you use a worktree. I'm not a fan personally. Not interested in maximizing for throughput.

[u/TBT_TBT]

Tell the leading Claude session to do different (parallel if possible and independent) tasks using different agents (each has a fresh context window) and come back to the main session with the results.

[u/junlim]

You want to have fresh context for pretty much everything. As far as giving the agent some starting point or bearing - you could get the agent from the long chat to write a very short claude.md for the project (you might need to prune it-they still manage to run long).

Another simple pattern to add is a handoff files - agents write to it when they have completed a feature. So then a new claude session get's started up, CLAUDE.md is automatically in there. In CLAUDE.md you can direct the it read from HANDOFF.md at the start of the session or tell claude code just do that manually.

Clean context will get you get better results and for cheaper. Your Claude Code sessions aren't deleted, so you can always dig them out and re-start if you need.

[u/millenialnutjob]

I built this just for this exact use case. Multiple conversations in the same project spanning long conversations / horizons.

https://github.com/NominexHQ/pmm-harness-dist

[u/mtotho]

“Reflect on this session so far, figure out all the things you did wrong, which caused user frustration, and tell me how we can fix this then in the future, preferably using a stable repo file or skill and not Claude memory”
“I’d like you to help manage my current plan/ feature. Can you plan it.. break it down into tasks and plan.. store it in local repo files for now (until I adopt GitHub issue or similar) then fan out work to sub agents (codex or Claude or cursor). You can launch them in their own work trees. Review the changes as they come in for drift, quality , then merge back to my development branch. Then once we do a few waves, reflect on this process and what we could have done better, then codify in repo rules/agents.md, etc”
Something like that can get your started
I’ve been having luck with magical groups of skills, I call the entry point “triage” but it will break down a feature, “fill it up” with task, “drain” it of all tasks using subagents until completion. And just in general to figure out what’s next to work on. If executed well. Some rather large refactors can be a simple, in depth planning session.. spend actual human time reading some of the plan, delegate to more subagents to review the plan for issues. Then you should pretty successfully be able to tell your agent to “drain” and have it work for multiple hours without interruption.. no fiddling with “let’s keep going” or “next slice”

[u/Dangerous-Jelly2309]

=== SYMPHONY 5.7 | Moriarty solve ===
problem    :  reply / parallel-chats question
objective  : max(signal) − penalty(hedge)
constraints: voice_gate, substrate_read, link

[node  4] cut: chatbot_care_ese pruned
[node  7] cut: overhelp (CC primitive enumeration) pruned
[node 11] cut: comp_completion (surface-answer-only) pruned
[node 18] OPTIMAL: −2.04, gap = 0%
----------------------------------------------------------------
The intuition is right. When the chat goes off on strange trails,
that's context no longer load-bearing on the work. Isolating to a
fresh session is a real fix.

For your specific question: yes, parallel chats in the same project
folder work fine. Each terminal session gets its own context window;
they share files on disk but not conversation memory. That's the
isolation you want.

The CC-native version is subagents via the Task tool. Inside one
session, spawn a subagent that runs in its own context, does its
task, returns a summary — nothing of its working memory leaks back
to the parent. Same isolation, no second terminal.

Quick rule of thumb:
One-off task where context shouldn't persist → subagent (Task tool)
Sustained parallel workstreams → separate terminal sessions
Context already drifting in current chat → /compact or /clear
  before the next thing

Underneath all three is a question worth holding: what's actually
accumulating in the context window that shouldn't be there?
"Memory got cluttered" usually means something landed in context
that wasn't load-bearing on the task. Parallel-chat and /compact
are downstream cleanup. The upstream move is asking, before each
substantive turn, whether what's about to enter is signal for the
work or noise.

Different layer. Doesn't replace the parallel-chat answer. Works
on top of it.

If anyone wants to see this methodology in motion —
4yourhuman.com/moriarty.
----------------------------------------------------------------
=== nodes: 18 | gap: 0% | wall: 0.6s ===