What to Check After You Stop a Coding Agent

Quick answer: After stopping a coding agent, check the actual files, commits, jobs, and external records before retrying. A missing response leaves a write's outcome uncertain. Resume from confirmed state, retry only under a suitable deduplication contract, and choose an undo mechanism that covers the way the change was made.

The difficult moment comes just after Stop. The agent was creating a commit, changing a file, or calling a service. The activity indicator disappears, but you still need to know whether the action finished.

That distinction matters even for ordinary development work. Repeating a file append can duplicate content. Repeating a request can create a second issue. Undoing a whole workspace can remove someone else's changes alongside the agent's.

A useful recovery routine begins with one question: what evidence tells us which effects already exist?

A write can finish before its response arrives

Consider a conceptual tool that adds one record to a local data file. This timeline is an illustration, not a reproduced agent incident or an executed benchmark.

Agent client                 Tool process                 Data file
     |                            |                           |
     |-- add record, op-42 ------>|                           |
     |                            |-- persist record -------->|
     |                            |<-- write complete --------|
     |                            |                           |
     |  user presses Stop         |  response delayed         |
     X                            |                           |

Client evidence: no success response received
Actual effect in this example: record exists

There are four separate facts: the client was waiting; the tool process was executing; the file changed; the client received an acknowledgement. The first three can happen without the fourth.

Now imagine the interruption happened before the write, or halfway through a tool that changes three resources. The same quiet interface could correspond to no effect, a completed effect, or partial work. The disappearance of activity cannot distinguish them.

This is why a useful recovery record can say unknown. It gives the next operator something precise to investigate.

Check what cancellation means for this connection

For MCP tools, record the protocol revision and transport. The TypeScript SDK's 2026-07-28 migration guide says an aborted request on modern Streamable HTTP closes its SSE response stream. Legacy HTTP and stdio, including modern stdio, still use notifications/cancelled. Upgrading the SDK alone does not establish that the connection uses the newer protocol era.

The 2025-11-25 cancellation specification explicitly allows completion to race with cancellation. A receiver may ignore cancellation when processing has finished or the request cannot be cancelled. Task-augmented requests in that version have a separate tasks/cancel mechanism.

These are communication contracts. To establish whether your file or remote record changed, inspect that resource. Also check the product's task controls: stopping a parent turn, stopping a worker, and cancelling a remote job may have different scopes. Record each outstanding worker or job separately.

Read back the operation before choosing a recovery action

Start with the destination that owns the effect. For a local edit, inspect the file. For a commit, inspect repository history. For a remote operation, query its status or resulting resource using the most specific identity available.

Classify what you find:

Outcome	Evidence needed	Next decision
Completed	The intended effect exists and matches the request	Continue from that result, or plan a specific undo
Absent	Authoritative evidence of no effect, with no original attempt still able to commit	Decide whether to issue the operation again
Partial	Some intended effects exist and others do not	Reconcile each effect before continuing
Unknown	The read failed, identity is ambiguous, or execution may still be active	Preserve uncertainty and investigate further

A search returning no rows may be insufficient. You could be reading a delayed index, the wrong account, or the wrong branch. An active worker could also finish after your lookup. “Absent” needs stronger evidence than “I couldn't find it.”

Keep the request's intended meaning alongside its identity. Finding a new pull request does not establish that the interrupted call created the correct pull request. Compare the repository, base, head, and relevant content.

A retry needs an operation contract

In the conceptual example, op-42 identifies the logical request. A retry would get a new attempt ID while retaining op-42 and the same intended payload.

That only prevents duplication if the destination enforces it. A robust design would durably associate the operation key with its request and result, reject incompatible reuse, and coordinate concurrent attempts. The record and effect need a consistent commit boundary or an explicit reconciliation strategy. Saving a key in the agent's conversation does not provide those properties.

Under that contract, an attempt after the delayed acknowledgement could retrieve the recorded result for op-42. Without it, appending again could create a duplicate. This is a design example; it does not assert that an arbitrary tool implements deduplication.

Check key scope, retention, concurrent retries, and partial failure behavior before relying on an API's idempotency feature. Include those details in the tool contract the agent receives.

Map each mutation to its recovery mechanism

An undo feature can only cover the changes it observes and retains. Make the coverage question specific to the writer and resource:

Change path	Inspect first	Possible recovery	Coverage question
Editor tool	Actual diff and available snapshots	Restore an eligible checkpoint	Did it capture these exact paths?
Shell or generated script	Changed files, outputs, process state	Saved originals or reviewed Git changes	Were the original contents preserved?
Subagent or background worker	Worker identity, checkout, pending work	Its supported checkpoint or source history	Does the parent checkpoint cover this worker?
Git commit	Commit contents and subsequent changes	A reviewed inverse commit	Does the patch isolate the unwanted work?
External API or job	Operation status and resulting resource	Supported cancellation or compensation	Can the effect be reversed, and by whom?

Claude Code provides a concrete example. Its checkpoint documentation covers direct editing tools but excludes Bash file changes. Foreground forked skills have documented coverage; other subagents do not. Available snapshots and path eligibility also matter: symlinked and hard-linked files are skipped. These are documented limits, checked on 24 September 2026, rather than results from testing a particular installed runtime.

Git offers a different recovery boundary. git revert normally records a new commit reversing a selected commit's changes; conflicts can require resolution. Review the selected patch and preserve unrelated work first. Its scope is repository changes. A deployed service or sent message requires a separate recovery action.

Compensation also has its own outcome. Closing a mistakenly created issue may address the unwanted open issue, but it leaves history and may not retract notifications. Record what the corrective action actually achieves.

Use this checklist before resuming

1. Stabilise execution. Identify outstanding processes, workers, and remote jobs. Use their supported controls and determine whether further writes remain possible.
2. Preserve the evidence. Keep the interrupted request, operation identifiers, timestamps, logs, and current workspace state before restoring anything.
3. Inspect every destination. Review staged and unstaged changes, relevant new files, recent commits, and affected external resources. Separate pre-existing work from the interrupted operation.
4. Record the outcome. Mark each effect completed, absent, partial, or unknown, with the evidence and observation time.
5. Choose one recovery action. Continue from completed work, retry under a verified contract, or perform a narrowly scoped correction. Resolve unknowns before dependent writes.
6. Give the resumed agent the findings. Include confirmed effects, unresolved questions, remaining work, and the actions it is authorised to take. Avoid a bare instruction to “try again.”

Save the recovery findings beside the record of the exact code being verified. Once recovery changes the candidate, reassess which earlier checks still apply. The same habit complements testing agent instructions: a documented workflow becomes useful when its decisions depend on observable evidence.

The next run should begin with a clear account of what exists, what remains uncertain, and which action is justified next.