Hand off work between Claude Code and Codex without starting over
What gets lost when design, review, and edits happen in different AI coding agents—and what a useful handoff should carry forward.
この記事を日本語で読む →
The work continues; the agent's context does not
A design decision made with Claude Code, a review finding from Codex, and an edit in Cursor can remain in three separate conversations. The person doing the work becomes the bridge, repeating the same background each time an agent changes.
A handoff should preserve the reason behind a change, not simply concatenate chat logs. That matters most after a break, when even the person doing the work may need to reconstruct where an investigation stopped.
The missing work often happened outside chat
Before asking an agent to edit code, you may read an issue, compare documentation, inspect a log, or try and discard an implementation. None of that necessarily appears in the agent's conversation.
Sharing only the conversation can tell the next agent what you asked for, but not always why you chose that direction. Browser and desktop activity can help recover the surrounding investigation, provided you verify which observations actually mattered.
Keep a timeline of the person's work
Imagine reading an OAuth specification on Monday evening, editing authentication code, asking Codex to review a diff, and reopening the task with Claude Code on Tuesday morning. The useful unit of memory is that sequence of work—not ownership by one agent.
Contextberg's approach is to keep desktop activity, browser history, and agent history on the user's side and make relevant context available through MCP. An agent can then ask for the previous work without becoming the sole owner of its memory.
What to include in a handoff
The next reviewer needs a short, checkable brief. More history is not automatically better.
| Context | Carry forward | Leave out |
|---|---|---|
| Goal | What the change is meant to fix and why | An entire early brainstorming chat |
| Constraints | Rejected approaches and existing project rules | Obsolete guesses |
| Diff | Files changed and unverified impact | Unrelated build output |
| Checks | Tests run, failures, and reproduction steps | A bare 'looks good' |
| Sources | Relevant issues, official docs, and PRs | Every page that happened to be opened |
A useful first question for the next agent
Before reviewing this diff, reconstruct yesterday's authentication refactor.
Separate the issues I read, files I changed, decisions I made, and concerns still open.
Then name the three parts of the diff that deserve the first review pass.
Cite the work history behind each claim, and mark anything uncertain.This does not replace reviewing the current code and running tests. It reduces the explanation needed before that review can start and makes uncertain memory visible rather than silently turning it into fact.