Hand a Claude Code task to Codex, Cursor, or tomorrow's session

Next action — carried

The task body. Markdown the owner writes before anyone claims it, and the first section of the handoff the next session reads — ahead of the project setup, ahead of the repository. A second field, the human instructions, holds the note addressed to the person rather than the agent; it shows on the task page and is deliberately never copied into the agent prompt.

Current branch — carried, as fields rather than prose

The repository and branch render their own section of the handoff. The delivery mode — none, push to the source branch, or branch off it — renders the line that says where the work has to land. After delivery, the delivered branch records what the runner actually pushed, and that value wins wherever it disagrees with what was planned.

Failed tests — not carried

Wagglet has no field for this. No column, no API field, no section that names a failing test. What it carries instead: the task body you wrote, the task's own comment thread with its attachments, and three switches — human QA with written instructions, screenshots, video — that say what evidence the delivery owes before it can be filed. A failing test name is something you type into prose. Nothing validates it, and nothing notices when it stops failing.

Constraints — carried, but split in half

Worth knowing which half you are writing into. Enforced by the handoff itself: required skills the agent must install and read before starting, a preferred-model check that stops the session rather than guessing, the workspace readiness check, and the hold every context prompt ends with — do not call any delivery API or change the task status from these instructions. Prose, in the task body beside the next action: every constraint specific to the change itself.

Definition of done — carried, as two separate things

The delivery contract says where the work lands and requires the runner to report the exact branch they pushed. The lifecycle then adds a second decision by a different person: claimed, delivered, done. A runner reporting that they are finished moves the task to delivered and no further. Sending it back is a first-class outcome, not an error path.

The transcript does not move. Record decisions, rejected approaches, and the next action in the task so the next session receives durable context instead of depending on yesterday's terminal history.

• Who may claim it is part of the task: required skills matched as any or all of them, named people who may claim it whatever their skills, and blocks that override both.
• No account, key, subscription, credit, or token allowance moves between people. The runner works under the agent subscription they already pay for, and the task carries no way to spend anyone else's.
• Delivery is scoped to the person holding the claim. Their delivery credential is minted for them and revokes every earlier one, so an old prompt left in a stale terminal cannot file a second delivery.
• The owner's note to the runner is separate from the agent prompt. It is addressed to a person, attributed to whoever wrote it, and never pasted into a session.
• Acceptance is a third seat. The person who wrote the task, the person who ran it, and the person who accepts it can be three different people.

• Paste it anywhere that takes text. The prompt is a task section, a repository and branch, attachments as absolute URLs any agent can fetch without a credential, the discussion, the rework history, and a closing that says where the work lands. Claude Code, Codex, Cursor, or a plain chat session all read the same thing.
• Only the context belonging to that task travels. The prompt is assembled from the task's own fields and thread — not from your session history, and not from the rest of the board.
• The one place a vendor is named is an optional check. A task that insists on a specific model tells the session how to verify which model it actually is, and to stop and ask rather than guess. That guard is opt-in per task and fails closed.

1. 01

   The context prompt

   Everything needed to do the work, plus a read-only credential that can refresh the task and nothing else. It ends with the hold: do not call any delivery API or change the task status from these instructions.
2. 02

   The work, supervised

   Human-supervised AI execution on the runner's own machine and their own subscription. The task can require a QA pass, screenshots, or a recording before a delivery will be accepted at all.
3. 03

   The delivery prompt

   Minted separately, by the person holding the claim, only while they hold it. Minting it revokes every earlier delivery credential, so an old prompt in a stale terminal cannot file a second delivery.
4. 04

   Review

   Someone else accepts it or sends it back with an explanation — and that explanation becomes the rework feedback the next session reads.

Can a Claude Code task be continued in Codex or Cursor?

Yes. Wagglet renders the task context as vendor-neutral Markdown that can be pasted into Claude Code, Codex, Cursor, or another text-based agent.

Does the original AI session move with the task?

No. The prepared task, repository and branch details, constraints, discussion, and delivery contract move. The original transcript and provider account do not.

How is delivery separated from reading the task?

The context prompt carries read-only access. A separate delivery prompt is minted for the current claimant when it is time to report the result.

For a repository-file alternative and a HANDOFF.md template, read the written coding-agent handoff guide.