Hand off code context between AI assistants

You stop a coding session with one assistant after reproducing a failure but before changing the right file. Another assistant will continue. “Pick up where we left off” means nothing in the second window, while pasting the whole chat buries the exact repository state under guesses, corrections, and dead ends.

Hand off a code checkpoint that a cold reader can verify.

Anchor the briefing to an exact repository state

Start with coordinates, not narrative:

• Repository name and location the receiving assistant is expected to access.
• Branch name.
• Exact commit or tag.
• Whether the working tree has uncommitted changes.
• Relevant file paths and what each path contains.
• Runtime, framework, or dependency versions that affect the task.

A branch name alone is not enough when it can move between sessions. Name the commit you inspected. If uncommitted work matters, describe it and preserve it through your ordinary version-control workflow; RelayLink does not store or transfer that diff.

The receiving assistant should confirm that its checkout matches the recorded state before acting. If it does not, stop and reconcile the difference rather than applying a correct idea to the wrong version.

Preserve observed behavior and exact evidence

Write what happened in terms another person could reproduce:

1. The command you ran.
2. The exact error or unexpected output.
3. The expected behavior.
4. The smallest reproduction steps.
5. Tests already run and their results.
6. Logs or traces that matter, sanitized of protected data.

Keep observations separate from hypotheses. “Test X fails with error Y at commit Z” is evidence. “The cache is stale” may be the first assistant’s inference. Labeling the second as a hypothesis gives the next assistant permission to test a different cause.

Do not summarize an error as “the build broke” when the exact message is available. The specific text may distinguish a compiler failure from a file lock, configuration problem, or stale output.

Carry decisions, constraints, and non-goals

Code context is not only files. Record the choices that shape an acceptable fix:

• Required behavior and compatibility boundary.
• Security, privacy, performance, or operational constraints.
• Plausible approaches already rejected and why.
• Changes explicitly outside scope.
• Tests or checks that define completion.

Then state the next ask as one bounded action: reproduce the failure, inspect two named files, propose a patch, add a failing test, or review an existing diff. Planning in ChatGPT and implementing in Claude uses the same checkpoint to move from design to code.

Avoid asking the second assistant to “finish everything.” A bounded first step reveals whether it actually has the right state.

Send the checkpoint to your own account

Draft the code checkpoint to your own email on the RelayLink account both coding assistants use. Review the repository coordinates, evidence, and next ask, then explicitly confirm it. RelayLink uses that one account without a contact request; no second account, email, or magic link is created. The checkpoint remains unread until any assistant pulls it, and the account portal is the fallback inbox.

This is a handoff of approved structured text, not automatic context sync. RelayLink does not move the repository, branch, working tree, source files, attachments, terminal or editor state, browser tabs, chat history, or hidden model context. The next assistant needs separate authorized access to the repository and development systems.

Researching in ChatGPT and building in Claude Code applies this boundary when sourced findings precede implementation.

Keep sensitive material in its authorized system

Never put API keys, webhook secrets, customer data, private logs, or confidential source in a handoff unless both the provider and receiving environment are authorized to receive it. Human confirmation of a RelayLink package does not override employer policy or provider terms.

Prefer:

• File paths instead of complete files.
• Commit identifiers instead of copied diffs.
• Secret names instead of secret values.
• Sanitized errors instead of raw customer records.
• Test fixture identifiers instead of production data.

If access cannot be granted safely, the task is not ready for that assistant.

Verify the handoff before changing code

Ask the receiving assistant to restate the repository state, run the named reproduction, and identify which claims are observations versus hypotheses. Compare its result with the checkpoint.

Only then should it change code. Afterward, run the focused test, the relevant broader suite, and any source-format or security checks required by the repository. One assistant’s explanation and another assistant’s implementation do not prove correctness.

A good code handoff does not recreate the first session. It gives the next assistant a precise, testable starting point and leaves the code where code belongs.