Continuity · · 7 min read
A task can outlive an agent session. Here is what must travel with it
Session resume, cloud handoff, and a cross-provider Task solve different continuity problems.
“Continue this task” may mean several different things. It can reopen the same provider session, connect a phone to a local process, move a cloud agent between devices, or start a new agent with a summary of earlier work. These paths preserve different kinds of state. A transcript can survive while a process has stopped. A cloud worker can stay alive while the local checkout has moved. A new provider can read a concise handoff yet know nothing about hidden context inside the old provider's session. The user's goal is the only stable anchor across all of those changes.
Claude Code, Codex, and Cursor document substantial continuity features inside their respective products. Claude Remote Control explains how server sessions can be resumed and how connected devices see conversation changes. OpenAI describes live Codex state from connected machines. Cursor for iOS describes moving between desktop, web, mobile, cloud workers, and Remote Control. Those are valuable native routes. GrantTap instead models a Task as the durable user-visible unit and an Execution as one provider-native attempt at it. This article examines what a careful handoff should preserve and what it must admit is missing. We checked vendor documentation on October 3, 2026.
Separate the objective from the conversation
The objective might be “make the failing payment test pass without changing the public API.” A provider conversation may contain many experiments, false starts, and tool outputs that matter only temporarily. If the conversation is the sole identity of the work, changing a provider or computer can make the user reconstruct the objective from hundreds of messages. A Task should instead hold a short human-readable goal, the project it belongs to, and the latest verified state. The transcript remains useful evidence, but it is not the identity of the work.
This distinction matters even when you stay with one vendor. Claude's Remote Control guide says connected devices can see the local conversation, with specific behavior for commands such as clearing or resuming a conversation. Cursor's mobile documentation says agents started on mobile appear on desktop and web; local IDE work can be moved or remotely directed through its supported paths. Codex exposes connected threads and project context through its mobile preview. These features make returning to a native session easier. They do not imply that a new, unrelated provider will automatically inherit private reasoning, permission mode, installed tools, or the exact state of a working tree.
Identify the repository and revision
A file path is not enough to identify the work. Two computers may have folders with the same project name but different branches, dependencies, or uncommitted changes. A cloud agent may use a worker checkout while the developer's laptop remains on an earlier commit. Before a handoff, record the repository identity, branch or worktree, current revision, and whether changes are committed. If there are uncommitted edits, say where they live. Without those facts, a new execution could produce a plausible answer against the wrong code and still appear to “continue.”
GrantTap's project and Task boundaries help organize that record, but the destination provider still needs actual repository access and compatible tools. A linked project does not merge repository permissions or silently copy files. The person approving the transition should inspect the target computer and checkout. A handoff packet should avoid secrets and raw prompt archives unless they are specifically required and safe to transfer. It should instead carry concise file references, commands run, test outcomes, and unresolved questions. A destination that cannot access the named revision should stop and report that limitation before making a new change.
Preserve decisions and constraints
Agent work accumulates human decisions: a rejected approach, a chosen API contract, a deadline, a prohibited command, or an approval limited to one action. These are easy to lose when a conversation is summarized as “continue implementation.” Put durable decisions in the handoff in plain language. Separate a decision that applies to the whole Task from a permission granted to a single execution. A one-time approval should not become a general authorization for a different provider. Likewise, a global capability deny on a computer should still govern any new execution there.
The receiving agent needs to know what is verified and what is only asserted. “Tests passed” is too vague; name the command, the revision, the time, and the environment where it ran. “Deployment complete” should include the destination and an independent check, if one exists. If the earlier provider reported a result but no host confirmation arrived, label it unconfirmed. This does not make the handoff verbose for its own sake. It prevents a new execution from treating a fluent summary as evidence and building on a false premise.
Resume, migrate, or restart deliberately
If you want the same conversation and the same local tools, native session resume or Remote Control may be the shortest route. Claude's guide describes resuming server sessions after stopping the server under documented conditions. Cursor describes moving cloud work between mobile and desktop and a separate Remote Control route for a personal machine. Codex's connected mobile state serves a Codex-native workflow. Before using any of these, check current product prerequisites and which component stays online. Do not call a view on another device a cross-provider migration simply because the phone now displays it.
If the original environment is gone or the work should move to a different provider, start a new execution with the handoff packet. Expect that it will need to read code and perhaps rerun tests. GrantTap can keep the Task visible across supported executions and show the transition; it does not transplant opaque model state. The new execution should acknowledge the goal, verify repository access, and state what it learned from the packet versus what it discovered independently. That honest restart often produces a safer result than pretending that every hidden context token survived.
Test continuity with a controlled interruption
Choose a harmless repository task with a small pending change. Start it in one supported provider, record the revision and a failed test, then interrupt the session. Try first to resume it natively from a phone. Note which conversation, diff, tool results, and approvals are visible. Next, hand the objective to a second execution or computer if your workflow calls for that. Compare its initial context with the handoff packet and ask it to identify missing information before it edits anything. Finally, rerun the test and inspect the checkout.
The GrantTap screenshot below is a deterministic demonstration of its handoff interface. It is not evidence that a particular provider copied a hidden transcript or passed a real test. An honest continuity claim is measurable: the next execution can name the right goal and repository, respect prior constraints, distinguish confirmed from unconfirmed work, and proceed from an explicit revision. If any item is missing, the UI should make the gap visible. Continuity is not the absence of interruption; it is the ability to recover without inventing state.
