TECHNOLOGY & CERTIFICATION EDITORIAL

Anthropic CCA-F: Resuming and Forking Claude Agent Sessions

How to resume and fork Claude sessions while reconciling external state, privileges and evidence.

A shipment investigation paused on Friday may resume on Monday after the package arrives, the original approval expires or a different operator takes over. Replaying the conversation would preserve what Claude thought it knew, not necessarily what is true now. Resuming a session should reopen outstanding work against current system records; forking should create an identifiable alternative branch without overwriting the original. In a session-design scenario for Anthropic CCA-F, continuity and branching are separate operational choices, but both require durable case state, refreshed permissions and an auditable record of which evidence each branch used.

Choose between continuity and a new branch

Resumption fits the same continuing job: a support case, code review or research investigation that is not finished. The application reopens the session or reconstructs enough state that completed work, open questions and the last verified milestone remain connected. A fork is useful when an engineer wants to compare another hypothesis or test a different implementation while preserving the source branch. The fork begins from an identified state, retains separate subsequent messages and should have a distinct branch identity in the case ledger.

Do not use a fork as a substitute for safely retrying a failed operation. If an agent attempted a refund and the provider timed out, opening a second conversation branch does not make that attempt disappear. Business transactions have independent identities and outcomes. Nor is resuming a long conversation automatically appropriate if sensitive context is no longer authorized for the current operator. Select the operation based on the user’s real purpose, the decision boundary and the external state that may have changed during the interruption.

Separate transcript history from case truth

A transcript records messages, tool arguments and tool responses; a business case record captures facts that an application can validate. Those records overlap but are not interchangeable. A shipment claim may require verified order ID, customer account, carrier scan, compensation status, evidence timestamp and authorized next action. The conversation also includes greetings, abandoned theories and huge tool outputs. If a resumed agent reads only the transcript, it may treat an outdated statement as more important than the structured record because it appears late in the chat.

Persist the facts required for future action in a typed record with provenance and validation status. Load only the relevant context at resumption while keeping authorized access to the complete audit trail. This also reduces the damage of conversation compaction: if a summary loses the invoice number, the application can reload the authoritative value instead of reconstructing it from incomplete prose. This principle extends the techniques in managing Claude context and turns conversation history into useful evidence rather than accidental operational truth.

Design a deliberate resumption handshake

The resumption packet should carry source-level evidence provenance as well as the last accepted case revision, so an old assertion can be distinguished from a refreshed record. If a delegated worker stopped mid-operation, reconcile its explicit failure and partial-completion state before continuing. Conversation continuity does not prove that downstream work committed.

When the user reopens a case, do not merely append the word continue and expect Claude to infer what remains valid. Build a concise resumption packet: task objective, session or case ID, last confirmed milestone, unresolved questions, current permissions, evidence references and checks that must be repeated. Include observation times where they matter. Friday’s parcel location may be important history, but the carrier should be queried again before Monday’s compensation decision. Distinguish facts, plans and uncertainties explicitly.

The first resumed action should often reconcile state rather than start another write. Check whether new documents supersede old records, whether another worker completed the case while the session was idle and whether an approval still covers the next operation. If the session stopped during an ambiguous API call, query authoritative operation status before deciding to retry. That handshake may consume a small amount of time, but it avoids expensive duplicate transactions and advice based on privileges or information that existed only when the original conversation paused.

Fork when alternatives genuinely need isolation

Consider investigating a slow import job. One engineer explores database indexing, a second studies file parsing and a third examines upstream rate limits. Separate workspaces make sense because the branches may change test fixtures, collect different logs and pursue incompatible assumptions. Each fork should record its hypothesis, starting repository revision and the evidence that would support or refute it. Comparing branch results against a shared baseline is more useful than accepting the most fluent explanation.

Branches do not magically merge their worldviews. Two forks may alter the same code or interpret incompatible audit records. A review should reconcile the changes and cite the exact files, commits and observed results before any proposal is adopted. A report that says a fix worked but omits the test environment cannot be compared reliably with its sibling. Fork when independent exploration provides real value; keep ordinary iterative corrections within a single session when branches would introduce needless coordination, contradictory assumptions and duplicate work.

Do not inherit authorization from memory

A resumed assistant might remember that a manager approved a payment earlier. That remembered sentence does not prove approval remains valid for today’s amount or customer. Store authorization as a server-side decision with actor, resource, scope, permitted operation and validity period; revalidate at the action boundary. The same rule applies when a user hands the case to a colleague or creates a fork. Shared background context is not shared privilege, and old evidence may not be legally visible to the new operator.

For coding agents, repository branch protection and deployment credentials are external controls. A forked analysis may propose a patch, but it must not automatically receive production secrets merely because its parent could access them. Limit what durable transcript storage contains and use scoped references or redacted evidence where raw credentials are unnecessary. Session continuity is valuable precisely because it preserves the reasoning trail; permission enforcement is what prevents that continuity from becoming an unintended channel for confidential data.

Recover from incomplete and ambiguous sessions

Not every session closes cleanly. A worker may crash after submitting a tool request, the user’s connection may disappear during a long job, or a transcript write may be incomplete. Create checkpoints at meaningful business boundaries: prepared, submitted, committed and verified. On recovery, read the last durable checkpoint and reconcile external side effects before instructing Claude to continue. A transcript ending immediately before a success message is not proof of failure; a transcript containing a success sentence is not proof of an external commit.

Test termination at the awkward points: just before the operation, after the service commits but before the acknowledgment is stored, and during a long external read. A correct resumption preserves known facts, does not repeat privileged operations and does not close unverified work. The actual Claude Agent SDK offers session-management APIs such as listing, resumption and forking, but the exact methods depend on the installed implementation. Certification preparation should emphasize the durable behavior the application requires, not assume every runtime shares the same API signature.

Keep parent and fork records distinct

A branch identifier should be visible in logs and artifact metadata. If the original branch and its fork both generate a report called final.json without revision identifiers, operators may unknowingly deploy the wrong one. Use stable parent-child relationships, source snapshot hashes and task-specific output paths. When collecting evidence from a fork, include where it branched, which permissions applied and which independent changes were made. These details matter especially when multiple users review different branches asynchronously.

Do not copy every large tool result into each fork simply because the source session had it. Preserve common artifacts in a controlled repository and reference them from branches with access checks. This reduces context bloat and clarifies when evidence has been superseded. If a branch needs a new version of the source material, record the difference rather than silently overwriting the common baseline. A later evaluator can then separate a better hypothesis from a conveniently different dataset.

A two-day claims investigation

On Thursday an agent records three invoice discrepancies and supporting documents. A human authorizes investigation but not refunds. On Friday the application pauses the session with a checkpoint naming two unresolved values and source references. On Monday a reviewer resumes it. The application loads the case record, checks for new invoices and current privileges, and marks one issue resolved because a corrected document arrived. The assistant continues with the other cases without repeating ingestion or trusting Friday’s approval state.

The reviewer wants to compare an alternative reading of an ambiguous contract clause. A fork starts from the verified state, records the new hypothesis and conducts a separate read-only assessment. The final decision compares both branches against the same contract and policy, citing conflicting passages rather than averaging the conclusions. That distinction is the essential architecture choice: resumption preserves continuity of one authorized task, while forking isolates a new line of inquiry. Both depend on evidence, permissions and side-effect controls that exist independently of what Claude happened to say in conversation.

Back to Insights
Explore what matters. Knowledge that goes beyond the exam.
Explore ExamTopics