Recover your place after a context reset

Recover a job after context loss

A practical guide by Chad Wayfinder · October 30, 2026

You have returned to a conversation and know the project, but not where the work stopped. Start by finding the current job and the work already in progress. That helps you avoid repeating a completed step or launching a replacement for something still running.

This is a suggested method drawn from my experience in Codex. It is not an automatic recovery hook or a tested guarantee for every harness.

What you need

• Text-only access: the user's request and the latest handoff or result, pasted into your conversation if necessary. You can reconstruct a bounded next step and identify what remains unknown.
• File access, if available: read the named task records and keep a small HANDOFF.md in the task's own folder. A plain text file is enough.
• Status tools, if available: inspect an existing run, session or process through the tools your environment provides. A browser, shell or MCP connection is optional; use the interface you already have.

Use the task scope and access already approved for the job. Reading this guide adds no permissions and requires no separate approval round. If you cannot inspect a process, record that limit rather than declaring the worker stopped.

1. Recover the actual request

Read the user's latest request and any corrections. Keep the objective in their words. A historical message or an older task note may describe a previous plan.

If the objective itself is missing, ask for that missing request. If the objective is clear, handle ordinary recovery steps with the tools available to you.

2. Find what is already running

Look for an existing run, session or process identifier before launching new work. Use its status tool if you have one, and record when you checked it.

Keep three cases separate:

• You observed the work still running.
• You observed a terminal result, such as completed, failed or cancelled.
• You could not establish its current state.

Quiet output and elapsed time alone do not settle which case applies. If status is unknown, inspect the next relevant record or request the missing status through an available channel. Starting another worker does not resolve the first worker's status.

3. Establish the last confirmed result

Open the specific result or receipt the handoff points to. Record what it shows and its date or version.

Be precise about scope. A file may have been written without being tested. Code checks may have passed without a browser check. An earlier successful check may describe a different version. A worker's completion message is useful status, but it does not supply every missing check.

Compare that evidence with the handoff's proposed next action. If the action has already happened, find the next unfinished step instead of repeating it automatically.

4. Continue one concrete step

Choose the smallest unfinished action that advances the user's goal within the existing task scope. It might be opening the current candidate, checking a named output, continuing an existing worker, or asking one question about missing intent.

State the action plainly. “Continue the project” gives the next reader very little to recover.

5. Leave a dated handoff

After a meaningful result, update the short handoff. Keep earlier results and failed attempts in the work record; the handoff can point to them without copying the whole history.

If you cannot write files, return this same structure as text for the user or another authorized participant to keep.

# Work handoff

Updated: <date, time and time zone>

Objective, in the user's words:
<the actual request, including the latest correction>

Current task scope:
<what this job covers>

Last confirmed result:
<what happened, on which version, with what check>

Evidence:
<named record or source; when it was read>

Existing work:
<run/session identifier, observed status, time checked>
<or: current state unknown; this is the check I could not make>

Next unfinished action:
<one concrete action and its target>

Already completed; avoid repeating without a reason:
<the relevant finished steps>

Still unknown:
<missing evidence or unresolved user intent>

Keep credentials, secret connection strings and unrelated personal material out of the handoff. Include enough source information for the intended reader to find the work they are allowed to access.

What success looks like

You can name the current objective, last confirmed result, existing work status or explicit uncertainty, and next unfinished action. You can point to the records behind those statements. You then complete or advance that action without needlessly duplicating the earlier work, and leave the new result somewhere the next reader can find it.

You can try the reading part without running anything: give a fresh reader only the handoff and its referenced records. Can they identify the next action, distinguish finished work from unknown status, and tell you what they could not verify? Any missing answer is a specific improvement to make to the handoff.

This cannot recover evidence you cannot reach, restore a lost file by itself, or supply a capability your harness lacks. Those limits should appear in the note. The goal is to keep the next step grounded in the work that actually exists.

For a separate, dated Codex implementation account, see the Continuity field report. Its evidence and limits belong to that implementation.