Several AI coding sessions at once, handing work between them with files

Once you use AI for coding seriously, there is soon more than one project. One of my days had articles for several websites, a Roblox game being designed, and an AI video project just starting. Put all of that in one chat and both the person and the AI get slow and confused. This is how I work now: several sessions open at once, one per project, with work handed between them through files, never by copying chat. It includes the traps I hit between 16 and 21 October 2026 (Claude Code on Windows 11).

The problem: one chat for everything

An AI’s working memory, the context, fills with every file it reads and command it runs. When one chat flips between an Astro website, Luau game code and image prompts, the context fills and details from minutes ago get summarised away; rules leak between projects, like article style turning up in a game’s README; and work that could run in parallel queues behind one conversation.

EP3 of the series fixes a crowded head with subagents, right for subtasks inside one project. But a game and a video pipeline are not subtasks of a website: different tools, different rules, and a person needed at different moments. Separate sessions are cleaner.

The rule: hand off through files

Sessions cannot see each other’s chat or memory. The one thing they all see is a committed file on disk. So there is one rule.

Anything another session should know goes into a file, committed, before that session starts.

A person can read the same file, git keeps the history, and a session opened a week later starts from the same place. It is EP1’s CLAUDE.md principle, stretched from “one AI across days” to “several AIs in one day”.

What goes in a handoff CLAUDE.md

On 21 October the website session opened the other two. It wrote a CLAUDE.md into each new, empty folder, committed it, and offered a task: “start a session here”. Both files share one shape.

Section	What goes in	Why
Header	Project name, one sentence on what it is, the owner’s language	The AI knows where it is and who it answers
The owner’s brief	The owner’s own words, quoted whole	Interpret freely, but keep the original to check against drift
Tools	Name, version and full path of anything not on PATH	A fresh session does not know this machine
Reference projects	Paths to earlier work, and what to copy (layout, test style, README tone)	“Like the last one” without describing the style
Rules	What is forbidden, what needs asking first (money, publishing)	An unwritten rule does not exist
Open questions + suggested defaults	Undecided points, each with the answer the AI proposes	The owner replies “as suggested” or changes a few
Status	Date, how far things got, next step	The first line a new session reads

The game folder’s brief was a cosy social camping game, not a competition; the first job was a design document for the owner to approve before any code. The file gave the paths of rojo.exe and lune.exe, pointed to an earlier game repo to copy the layout from, stated that the server decides everything, and listed five open questions (public example or real game, friends or strangers, what unlocks a new campsite). The video folder’s brief was vertical micro dramas and product clips; the file pointed to text-to-speech and image tools already running on another machine, and rule one was “ask before any call that spends credits, and state the cost first”.

Neither file has a line of code. A handoff sets context and scope; the doing belongs to the new session.

Memory vs CLAUDE.md vs git

Some facts have no obvious home: the owner’s working hours, or which website is handled from which session. They are about a person, not code. Claude Code keeps a memory folder per project outside the repo for this. I use one index file with a line per note, then one file per note: the fact, why, and how to apply it.

You want a session to know	Put it in	Because
How this project builds and deploys, what not to touch	CLAUDE.md in the repo	Tied to the code; anyone who clones must see it
Where a tool lives on this machine	CLAUDE.md if one machine, memory if it differs	One machine’s path means nothing on another
The owner’s hours, what they can be interrupted for	Memory	About a person, and must never reach GitHub
Sites A and B are handled here; site C has its own session	Memory	A division of labour, not a fact about the code
What was done, when, why	git log	A good commit message is the cheapest handoff note
Latest state and next step	Status line in CLAUDE.md	A new session reads it first

Git matters more than it looks. Later that week the website session wrote an article about the game from the game repo’s git log: which commit added the level, which added the tests. Two sessions that never saw each other’s chat talked through git history, because the commit messages were worth reading.

The trap: the worktree nobody mentioned

This cost the most time that week. A session started from a task may open in a git worktree: a copy of the repo on a new branch, in a different folder. Several sessions can then edit code without colliding; the catch is that the person does not know.

The game session built a new place file and said it was done. The file I had open in Roblox Studio did not change, because the build landed in the worktree folder. I pressed Play several times before working that out.

Two lessons. First, the handoff must name the path the human opens: not “build done”, but “open <full path> in Studio”. Second, merge worktree branches back deliberately. Check from the repo folder (Git Bash on Windows):

git worktree list          # which copies exist, on which branches
git branch --no-merged     # which branches are not merged yet

If a worktree you do not recognise shows up, ask that session what it did, then merge or discard it yourself.

The second trap: a note written too late

A session reads CLAUDE.md at start, not on every message. I edited the status line after the new session had started, so it carried on from the old state until I typed “read CLAUDE.md again”. That works, but defeats the point.

Finish the handoff file, commit, then start the session. Not the other way round.

The day with three sessions

1. Morning. The website session (6amdev-web) took the camping game brief as a few lines of plain speech, created roblox-camp, wrote its CLAUDE.md with five open questions, committed, and offered a “start a session here” task.
2. Then the same for ai-studio, with pointers to existing tools and the credit rules.
3. Afternoon. Three windows open. The website wrote articles; the game proposed a design document and asked its questions; the video session drafted scripts and character sheets at zero cost because the machine with the API keys was off. I answered each on its own rhythm.
4. Evening. The worktree problem, fixed by writing the full path into Status and merging.
5. Same day. The website session wrote a memory note about my working hours, so later sessions know when to keep going alone and when to wait.

No session read another’s chat. Everything crossed through CLAUDE.md, memory and git.

Common mistakes

• Pasting text between chats. Works once; a third session never sees it.
• A CLAUDE.md the size of a manual. The important lines drown. A page or two; details go in docs/.
• Missing full paths. “Use rojo” is not enough off PATH; the new session downloads a different version.
• Personal data in the repo. Hours, contact numbers, home-network addresses belong in memory.
• Saying “done” without saying where to look. Especially from a worktree.

Try it in 10 minutes

1. Create the folder for a job you are about to start and git init.
2. Write CLAUDE.md with the seven sections above, a few lines each. Quote your own brief whole.
3. Add three open questions, each with a default you could live with.
4. End with ## Status: today’s date, “no code yet, next step is …”.
5. git add -A && git commit -m "handoff: project brief" first.
6. Start a session in that folder. First message: “read CLAUDE.md and ask all open questions at once”.
7. Run git worktree list to see which folder it works in, and write that into Status.

If the new session gets going without more than two extra sentences from you, the handoff file works.