A session can lose context at a decision point
Claude Code release notes for version 2.1.291 describe fixes for cloud sessions that could drop answers to permission prompts and sessions that could lose their final messages when quitting. This is a narrow release-note claim about the product version, not a general statement that every session has this failure or that all task outcomes are now guaranteed.
The operational issue is broader than one tool: when a run pauses, disconnects, or closes near an approval, the person returning to it may not know whether the action happened. Repeating the step blindly can duplicate a write, send, or change. A reliable workflow treats the outcome as unknown until it checks the external system or an explicit completion record.
Define states users can understand
For any long-running agent task, distinguish waiting for approval, approval granted, action started, action completed, action failed, and outcome unknown. Show the last confirmed state with a timestamp and the action involved. If the session cannot prove completion, say that plainly and guide the operator to verify before retrying.
The approval interface should identify the specific action and target, not just ask a generic question. The user should be able to reject, approve once, or ask for more context. Log the answer and bind it to the action so a later session cannot reuse an approval for a different request or destination.
Make retries conditional on idempotency
A retry is safe only when repeating the operation has no harmful duplicate effect or when the system can recognize the same request. Use a stable request identifier for writes, check whether a record or message already exists, and make the operator’s retry choice visible. For operations that cannot be made idempotent, require a human to inspect the destination state first.
Keep retry rules separate for read and write actions. Repeating a search is usually different from submitting a payment, sending a customer message, or changing a permission. Make the action class part of the workflow configuration and test the recovery path with a simulated interruption before relying on it in production.
Test the interruption path
Create a staging test where a permission request is pending when the session is interrupted. Verify the user can see the unresolved request, the system does not silently proceed, and the task resumes without losing the intended target. Then test a tool call that completes but whose confirmation is delayed. The interface should distinguish a slow result from a failed action.
Capture enough evidence to investigate without exposing unnecessary content: action identifier, destination, approval state, result state, and timestamps. Check what happens after a user closes the window, loses connectivity, or starts another session. A release-note fix is useful context, but your own recovery behavior still needs an end-to-end check.
A practical upgrade decision
Before upgrading an agent workflow, read the exact release notes and verify whether the relevant fix is present in your installed version and environment. Reproduce the failure in a safe test, update, and rerun the same case. Keep an operator-visible recovery instruction for the period when different machines or accounts may be on different versions.
For a business process, the key acceptance question is not whether a session reconnects. It is whether the team can determine what happened and continue without duplicate or unauthorized action. If the workflow cannot establish that, the right fallback is to stop and reconcile the external state, not to ask the model to guess what it did.