How do I continue another developer's agent session?
By Soumen Sarkar · October 2026
Short answer: You continue another developer's agent session from its handoff, not its transcript: start a fresh session, give it the handoff and the area's recent decisions, and do the next step it names. The original developer doesn't need to be online.
Can I resume someone else's session directly?
Usually you can't, and you don't need to. Agent sessions live on one person's machine or account, and a long transcript is a poor starting point anyway. What you need is the state of the work: what's done, what's left, what was decided and what was assumed.
So the reliable way is to start a fresh session of your own and load it with that state. The work continues; the conversation doesn't have to.
What do I need before I start?
Three things, all of which should already exist if the work explains itself:
- The handoff: done, unfinished, next step, open questions, traps.
- The decisions in that part of the code: the calls already made there, so your agent follows them.
- The branch or commits: the code itself, which git already has.
If any of these is missing, look before you ask. The answer to "why is this half done?" is often in a commit message or a decision someone logged. If it truly isn't written down, state what you're assuming and keep going.
How does it work across time zones?
Here's a concrete case. A developer in Lisbon spends the afternoon on offline sync for the mobile app, in Mobile sync · app/sync. Her session ends at 19:00 her time with this handoff:
- Done: local changes queue in SQLite and replay on reconnect.
- Unfinished: conflict handling when the same record changed on two devices.
- Next step: apply last-write-wins per field, using the server timestamp.
- Open questions: assumed deleted records win over edits. Not confirmed.
- Traps: device clocks drift; never compare device timestamps.
A developer in Singapore picks it up the next morning, while Lisbon sleeps. He opens a new session, pastes the handoff, and tells the agent to read the sync area's decisions first. The agent writes the per-field merge against server time, which the trap warned about, and carries the open assumption about deletes forward in its own notes. Nobody waited for anybody.
What should my first instruction to the agent be?
Something like: "Continue this work. Read the handoff and the decisions for this area first. Do the next step it names. Keep any open assumptions visible, and add your own as you go." That keeps the chain intact: the next person after you gets the same quality of starting point you did.
When you finish, or stop, leave your own handoff. Continuing someone's work means you now own the note for whoever comes after.
Where does Campfyrr fit?
In Claude Code, Campfyrr writes the handoff automatically when a session stops, and shows it in the project's Activity feed as work paused partway, with its next step. To take it over, paste it into your first prompt. When your session first reads or edits that part of the code, it gets an area brief: who is changing it now, the decisions to follow, what changed this week, what was tried and dropped, and the open assumptions there. So the fresh session starts already knowing what the previous one knew.
The original developer stays offline, and the work keeps its pace. That's what letting the work speak means in practice.
Words used here
- Handoff: A handoff is what unfinished work carries for whoever continues it: what's done, what's left, the next step, and what to watch out for.
- Area brief: An area brief is what a person or agent is told the first time they touch a part of the code: what's changing there now, what was decided, and what was tried.
- Pick-up time: Pick-up time is how long a handoff waits between being left and someone picking it up to continue the work.
The principle behind this: Let the work speak: Our work explains itself, so nobody ever has to come and ask us.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).