Handing Work Between Coding Agents and People Mid-Task

To pause Claude Code mid-task, press Esc. The turn stops, the work done so far stays, and the session remains open for your next message. If you only want to steer, you do not need to pause at all: type while it works and your message is queued. To leave and come back later, name the session and resume it by name. What a pause cannot do is hand the work to someone else, because the session lives on your machine. For that you need a handoff note on the task, written while the agent still has the whole session in mind, and the same note works in the other direction when a person hands work to an agent.

Stopping a task for good, undoing its changes and stopping background work are covered in how to stop a Claude Code task midway. This piece is about the pause and the handover: you to yourself later, the agent to a person, a person to the agent, and one agent session to another.

Steer, pause or park

• Steer without stopping. Type a message and press Enter while Claude works. Claude Code’s interactive mode reference↗ (opens in a new tab) says the message is queued rather than interrupting, and reaches Claude as soon as its current tool calls finish. Press Up to take a queued message back.
• Ask without derailing. /btw asks a side question about the work while Claude keeps going, and the answer does not join the conversation.
• Pause. Esc stops the current response or tool call. Claude keeps what it has done, and anything you had queued is sent next.
• Park a long command. Ctrl+B moves a running Bash command or agent to the background so you can keep talking.

After Esc, the session is simply waiting. Nothing is lost by walking away for ten minutes. The questions start when the break is longer, or when the next pair of hands is not yours.

Pausing to come back yourself

Give the session a name before you leave, with /rename pay-retry or claude -n pay-retry at the start. Then claude --resume pay-retry brings it back. Claude Code’s sessions documentation↗ (opens in a new tab) lists what a resumed session restores: the full conversation, the model, and, when you resume from the terminal by name or ID, the permission mode it was in. Some things do not come back:

• Background Bash commands and monitors are not restored.
• Flags such as --mcp-config, --settings and --add-dir must be passed again; settings files are read afresh.
• A tool call cut off mid-run is not re-run. Claude is told to check whether it took effect before trying again.
• Anything that changed outside the session while you were away, such as a colleague’s push, is news to Claude. Tell it to pull and re-read before carrying on.

Two related controls are worth knowing. /branch copies the conversation so far and switches you into the copy, which lets you try a different approach while the original stays intact. And checkpoints are saved with the conversation, so /rewind still works after a resume, within the limits described in Claude Code’s checkpointing documentation↗ (opens in a new tab).

If the break is a train journey rather than a night, Remote Control↗ (opens in a new tab) lets you carry on the same local session from claude.ai or the Claude app on your phone, while it keeps running on your machine. That is still you handing to you.

Why a session is not a handoff

A session is stored locally, per project directory, under ~/.claude/projects/, and ages out after 30 days by default. A colleague cannot resume it. You can /export the transcript to a file, but a transcript is the wrong thing to hand over: thousands of lines of tool output in which the three facts that matter are buried. The person picking up the work needs a page, not a log. So does the next agent session, which would otherwise spend its first twenty minutes rediscovering what the last one learnt.

Agent to person: the note

The moment to write it is before you close the session, while Claude still has everything in context. Press Esc, then ask for the handover on the task it was working on. Write it for the reader, not for the record:

Stop here and hand this over to Priya. Comment on BUG-042 with:
- Where it stands: done, not done, and the branch and commit.
- What I need from you: decisions or answers only a person can give.
- What I assumed: anything I decided without asking, so it can be undone.
- Dead ends: what I tried that did not work, and why.
- How to check it: the command or page that shows whether it works.
- First step for whoever continues.
Then rewrite the plan on BUG-042 with what we now know.

“What I assumed” is the line people leave out and most regret. An agent working alone makes small decisions constantly: a default value, a library, which of two behaviours to keep. A person picking up the work needs to know which parts were decided by someone and which were guessed. Choices that will outlast the task belong somewhere more permanent than a comment; on a fenbs board that is the Decisions page, where an assistant can record a decision as an open question and only a person can decide it.

Already closed the session? You can still get the note out of it. The sessions documentation shows sending a follow-up prompt to a stored session from a script, which works just as well for a handover:

claude -p --resume <session-id> "Write a handover note for BUG-042: where it stands, what you assumed, dead ends, how to check it, and the first next step."

Person to agent: the handoff in

The other direction fails for the mirror-image reason. A person stops halfway with most of the context in their head, and the task says only what it said on the day it was filed. Before an agent picks it up, the task needs four things written down: the problem, the plan as far as it goes, the limits (what not to touch), and how the result will be checked. Giving an AI agent a task it can finish has the template.

fenbs makes this handoff explicit. A person can mark a task Pre-approved for AI and add its limits. The approval is of the task as written: if its title, problem or plan changes afterwards, it counts as an earlier version and no assistant takes it until someone approves it again. An assistant with nothing else to do calls fenbs_next_approved_task, which gives it the most urgent approved task in its project and holds it for a few hours so two assistants never take the same one. Comments added after the approval are information for the assistant, not instructions. When it finishes, it fills in how the work was tested and moves the task to Completed, and the card shows “AI done · check it” until a person presses “I’ve checked it”.

Agent to agent: give it back properly

An agent that cannot finish should not simply stop. It should say why and let go of the task, so the next session, human or not, does not find a claimed task with nobody behind it. On a fenbs board, fenbs_release_task does exactly that: the task goes back to Next Up and the reason is posted on it. For any other task, the equivalent is the handover comment above plus a move out of In Progress.

The next session then starts the way every session should: read the task, read the last comment, read the plan, carry on. It needs neither the old transcript nor the person who ran it. Which lane to leave a paused task in is set out in how to stop a Claude Code task midway; the short version is that In Progress should mean somebody is on it now.

Make it a habit, not an effort

Handovers are skipped when they are extra work. Put the rule in CLAUDE.md so Claude writes the note without being asked:

## Handing over
- When I say "hand over", or you are about to stop without finishing, comment on the
  task: where it stands, what you assumed, dead ends, how to check it, first next step.
- Rewrite the task's plan with what you learnt. The plan is for whoever comes next.
- If you cannot finish, move the task out of In Progress and say why.

• Name every session after its task, so claude --resume finds it and the task finds it.
• Commit before you pause for more than a day. A handover that says “uncommitted changes on my laptop” is not a handover.
• Read the handover before you trust it. A note that says “tests pass” is a claim until you run them; see verifying AI-generated work.