Opening a Copilot app session in VS Code and retaining its conversation and changes completes only part of a handoff. It does not establish that current files still match those last tested, or that processes, dependencies and runtime conditions resumed inside the editor.

GitHub’s October19, 2026 tutorial describes continuing the existing session and reviewing its associated worktree. The engineering question here is how to ensure the code reviewed, tested and submitted after handoff is the same code. Three distinct state layers and a content-snapshot example make that question concrete. 中文版.

What continuity the tutorial describes

The original tutorial presents Open in VS Code, retaining the task, plan and conversation while opening the session’s worktree and diff. It requires the app and editor to use the same GitHub account and appropriate repository permissions.

These are product descriptions, not results from a migration performed for this article. Preserved context helps explain implementation choices without reconstructing task history. Working in the same tree also reduces mistakes from copying changes between checkouts.

The entry point does not decide when a project is finished. A conversation statement that tests passed still needs a command, source state and environment. Treating it as current acceptance evidence converts a historical narrative into an unsupported live conclusion.

Separate conversation, files and runtime

Conversation state holds goals, plans, explanations and previous observations. File state includes committed content, staged and unstaged changes, and relevant untracked files. Runtime state includes dependencies, processes, configuration, databases and other external conditions. Sharing a task name does not synchronize all three.

A frequent mistake is assuming that an unchanged branch preserves test validity. Files can change repeatedly above the same HEAD. Another is assuming an existing directory means its server is running. Restoring files and restoring a process are separate operations.

A handoff record need not duplicate an entire conversation. Preserve the worktree identity, source baseline, uncommitted changes, unresolved questions and the particular state covered by validation. For private configuration, retain necessary identifiers without copying secrets.

The same repository is not the same worktree

The Git worktree manual describes multiple working trees attached to one repository, with per-worktree HEAD and index state. A familiar repository name therefore cannot establish that an editor opened the files associated with the session.

Check the actual directory, branch or detached HEAD, index and working-tree differences. If the directory is unexpected, locate the associated worktree before copying edits into a similar checkout. Copying can lose correspondence for new files, deletions, file modes or other uncommitted changes.

A detached HEAD is not automatically lost work; it is a reference state. Follow the project’s branching and PR process where needed. Force switching, cleaning or resetting unfamiliar state can destroy the changes that were supposed to be reviewed.

Bind test conclusions to their inputs

Suppose an agent successfully tested file state A. After opening VS Code, a developer changes a condition to state B. The branch and latest commit may remain identical, but the earlier result does not directly establish B’s correctness. This does not require every edit to trigger every test; it requires evidence to identify its subject.

For behavior changes, rerun checks that cover their impact. For text or layout changes, inspect the relevant presentation and neighboring states. Choose validation from the actual diff rather than avoiding it to preserve a claim that everything already passed.

Environment belongs to the evidence too. Identical source under different dependencies, configuration or services can answer different questions. Connecting a result to both a source snapshot and necessary environment identifiers helps a later developer decide what remains reusable.

Eight checks expose stale receipts

The example hashes a fictional in-memory mapping of filenames to text and compares a teaching receipt against current content and environment. It reads no repository, runs no project tests and operates no Copilot session. The invented receipt does not prove that a real test occurred.

# Synthetic content/test receipts; not a Git or Copilot migration tool.
import hashlib,json

def snapshot(files):
    data=json.dumps(files,sort_keys=True,ensure_ascii=False,separators=(",",":"))
    return hashlib.sha256(data.encode("utf-8")).hexdigest()

def receipt_matches(receipt,files,environment):
    return (receipt["snapshot"]==snapshot(files)
            and receipt["environment"]==environment
            and receipt["exit_code"]==0)

files={"main.py":"answer = 1\n","test_main.py":"assert answer == 1\n"}
assert snapshot(files)==snapshot(dict(reversed(list(files.items()))))
changed={**files,"main.py":"answer = 2\n"}
assert snapshot(files)!=snapshot(changed)
assert snapshot(files)!=snapshot({**files,"new.txt":"untracked demo\n"})
assert snapshot(files)!=snapshot({"main.py":files["main.py"]})
receipt={"snapshot":snapshot(files),"environment":"demo-env-A","exit_code":0}
assert receipt_matches(receipt,files,"demo-env-A")
assert not receipt_matches(receipt,changed,"demo-env-A")
assert not receipt_matches(receipt,files,"demo-env-B")
assert not receipt_matches({**receipt,"exit_code":1},files,"demo-env-A")
print("8 handoff-evidence checks passed")

All eight checks passed locally: mapping order is irrelevant, while changed, added or deleted files alter the snapshot; changed content, environment or exit status invalidates the receipt comparison. Branch names and HEAD alone are deliberately insufficient because uncommitted edits can change the subject.

The digest covers only files explicitly included. It is not a complete build fingerprint. Decide whether ignored files, dependencies, generated inputs, compiler options or external state belong in a project-specific definition. Matching digests establish only equality of selected inputs, not sufficient testing or authentic receipts.

Define the snapshot’s file selection before using it as evidence. Hashing arbitrary private configuration is not a substitute for deciding whether it belongs in a shared record; a digest alone is not a privacy or provenance guarantee. Preserve only the project inputs needed for the stated comparison.

Review intent before asking the agent to continue

Read the actual diff first. Check whether each change is required, whether error paths and boundaries are handled, and whether unrelated behavior moved. Conversation history can explain a choice while still disagreeing with the code eventually produced.

When asking for further work, state the remaining problem and known facts. A specific untested input boundary is easier to validate than a request to keep optimizing. Review the final differences again after edits so manual and subsequent agent changes do not overwrite one another unnoticed.

Retain unresolved acceptance work. A device test remains unfinished even if the session changed interface or its test command starts. Successful compilation, protocol checks and real usage can require different evidence.

Inspect additions and omissions before submitting

The git status manual distinguishes index, working-tree and untracked content. One diff view can miss new files outside that comparison; the latest commit can omit a still-uncommitted fix. Check the expected file set before committing rather than indiscriminately staging everything.

Review intended changes, then use the repository’s normal commit and push process. A push transfers a commit; it does not establish that a PR merged, deployment finished or a user accepted the behavior. Reporting those states separately prevents handoff from becoming an accidental claim of release.

Worktree isolation also does not guarantee separate databases, ports, caches or credentials. Verify how the project isolates runtime resources instead of treating a Git directory structure as a complete environment sandbox.

Leave evidence another developer can continue

The tutorial provides continuity from an agent app to an editor. The checks here add a separate requirement: the next developer should know what changed, which state was verified and what remains unresolved. Conversation continuity becomes useful work continuity when those observations are preserved.

The earlier ambient-intelligence acceptance discussion asks how results are checked after quick triggers. Here the checkpoint is an editor handoff: context saves explanation, while verifiable state supports the next decision.

If the state distinctions and snapshot example help avoid stale test conclusions, voluntary support through the section below is welcome. The reusable outcome is a work record understandable to the next person, beyond a successfully opened editor window.

Sources and backfill note

October19 original tutorial、Git worktree、Git status

Discovered through Google News and checked against the original October19, 2026 publication and linked primary documentation. The event predates the planned October20 22:00 Beijing slot. The examples and diagrams are original teaching material. This missed slot retains its planned article date; actual backfill time is verified separately. No account policy was changed or Copilot session migrated.