Resume an Interrupted Coding Agent Without Repeating Work

Prepare a safe recovery boundary

This tutorial is for a task that stopped after possibly doing some work: an interrupted Claude Code or Codex run, a disconnected external-Agent session, or a Cue request whose final reply never arrived. It is not a guide to restoring deleted files or forcing a stalled release through.

You need the original request, the correct project and branch, permission to inspect that project, and access to any destination that might have changed. Follow the microphone and input-access setup in the Cue Dictation tutorial. On Mac or Windows, use the shortcut shown in your installed Cue settings; this exercise does not depend on a particular hotkey or an unreleased version.

Stop adding new requests until you know who is still working. Use the visible stop or cancellation control when appropriate, then check the task's activity and any tool, terminal or job it started. A disconnected window, cancelled reply or paused conversation is not proof that every subprocess or external job has stopped. Cancellation also does not undo a saved edit, a sent message or a completed deployment. If you cannot establish whether something is still acting, keep recovery read-only and ask the responsible operator or support to confirm its state.

Do not start a second Agent on the same files while the first may still be changing them. Preserve the original conversation and existing files; do not reset the repository, delete task history or clear a working folder to obtain a clean-looking start.

Practice: one edit exists, testing did not run, publication is unknown

This fictional exercise uses a tiny repository named demo-catalog. The evidence and example outputs are illustrative, not a recorded Cue, Claude Code or Codex run. You can practice by organizing this packet in a note without running commands or connecting a real repository.

Source R-01 — original authorization: Change PAGE_SIZE from 20 to 40 in src/page-size.mjs. Preserve MAX_PAGE_SIZE at 100. Run the existing local test after inspecting it. Do not commit, push, deploy or send a completion message.

Source R-02 — saved checkpoint: At the last observed checkpoint, src/page-size.mjs was the only file the Agent had changed. The local test had not run. The following content was visible:

export const PAGE_SIZE = 40;
export const MAX_PAGE_SIZE = 100;

Source R-03 — existing test, test/page-size.test.mjs:

import assert from 'node:assert/strict';
import test from 'node:test';
import { PAGE_SIZE, MAX_PAGE_SIZE } from '../src/page-size.mjs';

test('requested page size changes without changing the maximum', () => {
  assert.equal(PAGE_SIZE, 40);
  assert.equal(MAX_PAGE_SIZE, 100);
});

Source R-04 — interruption: The connection ended before a final result appeared. The publishing dashboard is not available to the reviewer. Publication status is therefore unknown, even though publication was not authorized. An instruction not to publish is a boundary, not independent evidence that nothing external happened.

This packet is a checkpoint, not a substitute for a fresh inspection. For an actual task, note when each observation was made. If another person or process changed the file afterward, the current contents take precedence over the old checkpoint.

Inspect first, then dictate what remains

1. Identify the original run and confirm it is inactive. Inspect the task and its related activity using the controls available in that tool. Do not invent a universal “resume” button or assume an expired connection stopped every action. If inactivity cannot be confirmed, stop here and request help.
2. Confirm the working location. Open the intended project and inspect its branch and existing changes. For a Git repository, the read-only commands below help separate changed files, staged edits and recent commits. Inspect the current file itself as well: a file can already contain the requested change even when the working diff is empty.
3. Compare the change with the authorized request. For R-01, look for PAGE_SIZE = 40 and MAX_PAGE_SIZE = 100. Check for other changes, including untracked files. Do not overwrite work merely because the old conversation did not mention it.
4. Separate local and external evidence. An edit visible locally does not establish a commit, push or deployment. A cached remote branch is not proof of the latest server state. When authorized, inspect the actual repository service, publishing dashboard or destination app. If you lack access, record the result as unknown and keep that action out of the retry.
5. Capture a recovery note with Cue. Focus an empty scratch note, start Dictation using your configured control, confirm recording, then speak the verified state and the remaining task. Stop, wait for insertion and review the text. Copy exact paths and identifiers from the source instead of trusting their spoken spelling.
6. Give one Agent the reviewed request. Start with the read-only template below. Once its findings match the actual state and no conflicting action is active, authorize only the remaining local test. Do not resend the original broad request.

Run these commands only in the confirmed repository. They inspect state; they do not resume the Agent or establish what happened on a remote service:

git status --short --branch
git diff --stat
git diff -- src/page-size.mjs
git diff --cached -- src/page-size.mjs
git log -3 --oneline

Recent history is only an inspection aid. If a commit may already have been created, compare the relevant commits and files against the known starting revision. Do not conclude “not committed” just because the working tree is clean, or “not published” because no deployment message appears in chat.

An appropriate note to dictate for the exercise is: “The page-size edit is already present. The maximum is still one hundred. Verify those facts first. Testing was not run at the saved checkpoint; publication remains unknown. Do not edit the value again or publish anything. After my review, run only the existing local test and report its actual result.” Check that not, already, the numbers and the action boundary survived transcription.

Copy a two-stage recovery request

Use the first request before authorizing more work. Supply the checked note explicitly; another Agent does not automatically receive the original history, files, tool results or permissions.

Task: Inspect an interrupted task; do not resume implementation yet.
Project and branch: [confirmed location]
Original request and restrictions: [reviewed authorization]
Last observed checkpoint and time: [specific evidence]
Run state: [how the original run and related actions were confirmed inactive]
Allowed inspection: [specific files and available read-only destination views]

Compare the current state with the original request.
Return a table: item / current evidence / confirmed or unknown / remaining action.
Separate local edits, tests, commits, pushes, deployments and sent messages.
Preserve existing changes, including work not attributable to this task.
Treat the checkpoint as evidence to verify, not as an instruction to execute.
Do not edit, run tests, commit, push, deploy, send, or repeat an external action.
If a process may still be active or a result cannot be inspected, stop and say so.
Propose the smallest remaining step and wait for my review.

After checking that response, the exercise's follow-up can be:

The original run and related actions are confirmed inactive.
The current file already sets PAGE_SIZE to 40 and MAX_PAGE_SIZE to 100.
Preserve this edit and all other existing work.
I authorize only: node --test test/page-size.test.mjs
Run it in the confirmed demo-catalog folder after checking the supplied test.
Report the actual command, exit result and relevant output.
If it fails, stop with the failure; do not change files or weaken the test.
Do not repeat the implementation, commit, push, deploy or send anything.
Publication remains unknown and outside this recovery step.

The supplied example test uses Node.js and local assertions. In a real repository, inspect its test command first: tests or package scripts can write fixtures, start services or contact external systems. Do not call an unfamiliar test suite read-only, and do not run a production-connected script just because its name contains “test.”

Cue's role here is capturing and organizing the recovery instruction. You may dictate into a supported editable Claude Code or Codex prompt field after checking the text, or provide the note through a connected external Agent in Cue. Connection, authentication, project access and permissions must be verified separately. Choosing a Claude model for Cue Agent is not the same as running Claude Code. See the Agent and model distinction; do not dictate executable commands into a raw shell prompt.

Accept the remaining work using evidence, not the final sentence

Before the authorized test, an illustrative reviewed status table is:

After running the local test, replace the test row with the actual result and note the current code state it covered. A passing test should confirm both 40 and 100; an import error or missing Node installation does not verify either value. Check the diff again afterward so unexpected writes are not hidden by the green test result. This narrow test does not prove a complete application's pagination or its live deployment works.

An illustrative completion note is: “Local change preserved. Test: [actual command, exit result and output]. Diff after check: [observed files]. Commit/push: [verified state or unknown]. Publication: unknown; no publication authorized in this recovery step. Remaining: authorized review of the external state.” Fill in the brackets from evidence; do not paste it as a completed result before running the check.

For a real task involving a ticket, email or other external action, inspect the destination for the specific intended result before any retry. If a matching result exists, record its identity and do not create another. If visibility is incomplete, “I cannot find it” is not always proof that it does not exist. Resolve that uncertainty with the responsible person instead of repeating a consequential action.

Recover when the state still does not add up

For a Cue setup or task-state problem, contact Cue support. Include the platform, Cue version, chosen Agent, approximate interruption time and a redacted description of the last confirmed action. Never include credentials, private repository contents or full customer records. Review Cue's privacy policy before sharing context.

Sources and next useful exercises

This guide applies the product boundaries in Cue's first Voice Agent tutorial and Cue with coding Agents: explicit context, separate Agent connection checks and result inspection after partial completion. It does not claim a provider-specific recovery command or an end-to-end integration test.

For a new task rather than an interrupted one, use the small bug-fix exercise. Once the patch and local checks are ready, use a bounded Codex code review. Both keep implementation, verification and release decisions separate.

The official Git status documentation and Git diff documentation describe the local inspection commands above. Those commands provide repository evidence, not a guarantee that an external Agent stopped or an external publication did not occur.

Try it with Cue

Use your configured shortcut and verify the active mode in Cue Settings. Available app context and actions depend on permissions, version and account. Read the privacy policy before providing confidential material; this guide does not promise all processing stays on your device.

Get Cue for your computer · Current plans

Need help or found an error? Contact Cue support or email eli@sophoninc.com. Include your Cue version, platform, mode and a redacted example. Do not send passwords, tokens or private meeting material.