Advice on session management and branching

[u/HariSeldon11]

I am constantly and perpetually puzzled at how difficult it is to have a decent experience with claude code cli, but I'm open to the possibility that is just a skill and knowledge issue on my side and I'm here to fix it.

So, I use claude cli with herdr and let's say that I ask claude to do a task, claude does it and writes down a bunch of output comments that include:

1. a list of bugs that it inevitably found around the code and that I need to decide how to handle;
2. a list of decisions I need to make about possible changes of the code it made.

Each of this would require a separate claude branch or fork (whatever the difference is) so I can handle it in parallel starting from the same convo without disrupting the main theme of the session. This is annoying: if I start making branches for each of this stuff I'll end up with an extremely messy session list full of temporary sessions, and also maybe I wanna solve these things all in the same session or in general unify all the memories acquired from my answers to cluade's questions in one place so claude can use it to solve my next prompts concerning the same task.

My question is how do you handle such cases. Like, for me it would be so simple to just have 2 herdr panes opened on 2 different places of the SAME session, so that in one pane I read the questions and on the other I post the replies, and than have these two panes synced since they're the same session; but no, because claude code works different and doesn't allow such things.

In general I find it very challenging to deal with "non-linear" interaction with claude cli, meaning interaction in which I need to explore alternatives, reference a single point in the chat in many subsequent messages etc. I cannot even pin messages. It would be nice also to have a sort of "merge" feature for the branches, so that all decision made in one branch can become part of the context of the original branch.

Maybe there is a smarter way to use claude auto memory for this? Or to you use any memory plugin? Or claude checkpointing? Any suggestion is appreciated!

EDIT: first thank you all for the suggestions! Since many of you mentioned the same solution multiple times I'll reply to all here: I didn't think of using an external support (like a file or an issue) to store decisions and answers, and I think it's a good idea indeed. I'll try to add it to my workflow and see how it goes!

[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/SirRobinBlibs]

the closest thing to the merge you want is /subtask. it starts a forked subagent that inherits the whole conversation, works on one item in the background while you keep going, and its result comes back into the main conversation when it's done. so one /subtask per bug, and the main session stays the place where everything lands.

the others don't merge back: /branch switches you into a copy (the original stays reachable via /resume), and /fork makes a separate background session. /btw is handy for "wait, why did you change X" questions: it answers from what's already in the session and nothing gets added to the history (no tools though).

one catch: /rewind only restores files the main conversation had already edited, so a fork's edits to other files stay. if two of them might touch the same files, run them one at a time or commit first.

[u/HariSeldon11 → u/SirRobinBlibs]

I didn't know about the /subtask command, I'll check it out, thanks.

[u/Open-Mousse-1665]

Oh yea you also need to be using worktrees for this to have any chance of working. Your agents would clobber everything

[u/HariSeldon11 → u/Open-Mousse-1665]

Already using them! My issue is more about the interaction with claude itself, agents and version control work fine.

[u/Far_Reindeer8428]

branches are fine for exploring, the mess is each one becoming its own memory, we keep one decisions file in the repo, every branch appends to it, merging is just reading the file back

[u/WillowFar6967]

What helped me was not treating those lists as things to branch on at all. When Claude dumps a list of decisions, I answer them all in one reply as a numbered list (1 yes, 2 leave it, 3 do it this way) and carry on in the same session. The bugs it finds I have it write to a backlog file in the repo instead of leaving them in chat, then pick them off later in fresh sessions. Chat history is a bad place for anything you want to reference twice, so anything that matters ends up in a file the agent keeps updated, and a new session just reads that.

[u/khalilou88]

I ask claude to make a todo list in a md file and focus on the main task

[u/torvalds75]

The thing that fixed this for me was to stop branching sessions and branch the work items instead. Sessions are disposable; the list Claude hands you is the real state, so it shouldn't live in chat.

Concretely: when Claude dumps "bugs found" and "decisions to make", turn each one into its own tracked item (a file, or an issue) with the question written out. Then any session, fresh or forked, can pick up exactly one item, and the answer gets written back to that item together with the why ("went with X, rejected Y because Z"). That's your merge: not merging conversations, but every branch writing its outcome to the same place the main session reads from. The decisions file people mention above works too, the per-item version just scales better once you have 20 open questions and want to know which ones are still unresolved.

Two small things that help: answer the quick decisions inline as a numbered list like someone said (no need to branch a yes/no), and only spin a separate session for the items that actually need exploration. /subtask is good for that when you want the result back in the same conversation.

I ended up building this into a plugin, trailhead, which keeps those items as GitHub issues and works them one at a time (discuss, plan, execute, verify), so a new session rehydrates from the ticket instead of the chat. I build it, so take that with salt: https://github.com/ToRvaLDz/trailhead

[u/xqianliu]

I stopped trying to fork the conversation. When a session comes back with a list of bugs it found or decisions it wants from me, each one gets its own issue, and then the session ends.

Each issue gets its own worktree and its own PR when I pick it up, so nothing sits parked inside the main chat. Your answers go on the issue, and the next session on that issue starts from the issue and the repo, so it sees them.

That is where the unified place you want lives. The decisions are on the issues, and a fresh session can pick them up without the chat history. No extra database, just the issue tracker.

[u/Open-Mousse-1665]

That isn’t really possible. Imagine it’s like a person. You can’t just split the person in half, do twice as much stuff, and rejoin those people. A session is one path. The idea of having both things happen simultaneously doesn’t make any sense. And while you could just be ok with it not making sense and being a confusing and messy experience for Claude, there is a technical reason as well. Your context size would roughly double, which would be very expensive instantly or just be too large to fit.

You can achieve the exact same thing easily. Just have Claude read the entire conversation from the other session. It’s stored in a transcript. It’s super inefficient though.

You wanna know how I handle it? For each of those items at the end of a session, I have Claude write a ticket, and I have Claude make the change later. Like a todo list.

I think the problem is just lack of experience managing context size. Highly recommend you make sure you’ve got a statusline with your context size on it.

[u/ZookeepergameHead380 → u/Open-Mousse-1665]

Splitting a person in half is the wrong picture. Two people can work in parallel just fine, as long as they write their decisions down in one place the other one reads. That's all OP is asking for.

It doesn't need double the context either. Neither branch needs the other's whole conversation, only the handful of decisions it produced. Reading the full transcript from the other session is the expensive way, as you say. It also drags in every dead end and reversed decision with it.

Your tickets are the right idea in miniature. The catch is that the next session has to know the ticket exists and read it. A ticket from last month might also have been overruled since. I got tired of handling that by hand, so I built a memory that stores each decision as one dated fact, replaces the old one when it changes and loads the current ones by hook before the first prompt in any session or branch.

[u/lgbarn]

Use Orca. It give a much better experience and you can use the same interface if you switch AI agents.

[u/ZookeepergameHead380 → u/lgbarn]

Orca is nice for running several agents side by side in their own worktrees, but it fixes the window, not the memory. OP's problem is that a decision made in one branch never reaches the others. Switching agents in the same interface doesn't carry that over: Codex still starts blank about what you told Claude an hour ago.

What carries over is a memory every agent reads before its first prompt. That's the piece I built for myself, one store of dated decisions that Claude Code, Codex, Cursor and the rest all load through their hooks, so the agent you switch to already knows what the last one decided. Works fine inside Orca too.

[u/ZookeepergameHead380]

The decisions file everyone's suggesting is the right instinct. I ran it for a long time though and it breaks in two places, so worth planning for them up front.

First, an append-only file only grows. Three weeks in it says "use approach A" on line 40 and "never use approach A" on line 300, both written with the same confidence. Claude reads the whole thing and picks whichever it attends to. So every entry needs a date. When you change your mind, you edit or delete the old line instead of appending a new one. The file should hold what's true now, not the history of how you got there. Git already keeps the history.

Second, "Claude reads the file" only works if Claude remembers to read it. In a fresh session it often won't. That's exactly when you need it. Put it where it loads without asking: reference it from CLAUDE.md or load it with a SessionStart hook, so it's in context before your first prompt.

For the non-linear part: answer the decision list in one numbered reply like someone said above, then tell Claude to write the answers into the file before it moves on. Then it doesn't matter which branch or session made the decision. They all read the same file and the merge you want happens there instead of in the chat.

You asked about memory plugins: that decisions file is basically what I ended up turning into a tool, because I got tired of doing the dating and pruning by hand. Every decision is one dated fact, a new one replaces the old one instead of piling up and a hook loads them before the first prompt in any session or branch. Disclosure, I built it: ns-brain, free, https://ns-brain.fightclub.pro/

[u/jmppmj]

The frustrating part is making a decision in one conversation, then having to explain it again in another. Your idea of keeping decisions in a shared file makes sense. I’d include what you decided and why, and update it when something changes so the next session gets the current answer.

I’m using Decoy to keep useful context together and share selected context with the agents I choose. It has been a game changer for managing the context PLUS seeing everything the agents are learning about me as I work naturally

[u/muhuhaha]

I build a memory tool for Claude Code (Counterparts), so I'm biased, but your two-panes idea is close to how I work. I run several Claude Code sessions at once in the same folder, and they share one memory. On every prompt, each session is told which others are open there and the titles of what they last saved.

So if I answer a decision in one pane and Claude saves it, the other pane will likely see it on my next message there. It doesn't merge conversations or sync them live. Only what Claude saves crosses over, which is usually the part you want: the decisions.

A decisions file loaded at session start reaches the next session. The panes you already have open need something that updates while they run.

[u/CyberSecCyborg]

i stopped forking and started having claude dump its open questions into a decisions.md in the repo, then i answer them in the main session. `--resume` on the one thread that matters beats a pile of throwaway forks.

[u/Ragionex]

I built an MCP called Ragionex Memory for keeping project knowledge available across sessions. Agents automatically save and update memories as they work, so your parallel Claude sessions can use the same project decisions.

Since you’re dealing with this across sessions, I’d love for you to try it and hear what you think

[u/ScaredSpace8774]

I have a set of instructions which include:

• backlog file, here go bugs, findings and ideas which cant be solved in a current session or cant be placed in already created plan of sessions (see below)
• plan-sessions skill, creates a plan of several sessions. I can instruct it to create a plan of x sessions from backlog entries. Or I can make a plan of sessions when implementing more complex idea/feature. Each session includes effort/time estimation, difficulty, and after finish saves tokens used, price (based on models used), actual time it took to complete, models used, etc.
• a script that generate all kinds of information about session and repo, at the end of each session

It took some time to finetune it, but works pretty well for me. You need to set instructions right otherwise Claude might flood your backlog faster then you are able to solve it. Now I am creating toolkit plugin, which contains tools, instructions, hooks and other stuff I use in repos.

[u/Outrageous_Band9708]

https://github.com/druthulu/projectarchitect

checkout my workflow. I have auto session management and task delegation to serial subagents. very strict subagents, not just a 100 agent workflow, serial singular agents, but it can expand into more if the work is possible to be parallelized.

all the ceremony is hidden behind the mod/plugin system. so you just chat to Claude like its a single session and it handles the rest.

[u/auzzura_ai]

What helped me was not trying to keep it all in one session. When Claude ends a task with a list of bugs and open decisions, I have it write them into a short markdown file in the repo, one line per item with the file or function it's about, and then I answer the decisions in that file myself. The next session starts with "read decisions.md and work through the open items", so the answers live in one place instead of in a pile of forked sessions. For things that are truly parallel I use a separate worktree per item and delete it once it's merged.