I replaced a long-running Codex role task. Not deleted — handed over to a successor with the role intact.
The conclusion first: do not copy the conversation. Copy the state that is still in force. A long thread carries rejected proposals, intermediate errors, stale assumptions, and completed requests. Duplicating all of it starts the successor from a position where nothing is clearly the record.
Originally published in Japanese on July 20, 2026. This English version was written in September 2026.
I ran this on three role tasks. Each one exposed a different oversight: a scheduled task’s delivery destination, an unread handoff, and a stale acknowledgement. The gates below accumulated one failure at a time.
What actually needs to transfer
Not the conversation. This list:
- What role this is
- How far it is permitted to act
- What it must never decide alone
- What is complete and what is not
- The specific next action
- Who picks it up on failure
- Which checks must finish before any external operation starts
Codex does provide an official mechanism for repo-scoped standing instructions: AGENTS.md, read before any work and concatenated from the repository root down, with files nearer the current directory taking precedence.
Everything else here is mine. The migration manifest, stable reference names, the pending-handoff holding area, direct acknowledgement, independent QA — none of that is a Codex migration feature. Keeping official capabilities and local practice apart turned out to be part of the handover material itself.
Fix the rollback point before creating the successor
I audited the old task before creating anything. The question was not “can I build the successor” but “can I get back if this fails.”
Can the role, permissions, prohibitions, current objective, open items, and next action all be explained from the documents of record alone? If anything requires re-reading the conversation to decide, the task is not ready to rotate.
Then I snapshotted references, scheduled tasks, pending handoffs, working environment, and the old task’s state — metadata only, meaning identifying state and nothing else. No prompts, responses, tool output, transcripts, credentials, or database contents were copied.
I also closed every in-flight external operation. With an unsaved edit, an unsent post, or a running deploy outstanding, which task owns the consequence becomes ambiguous.
Failing the preparation audit means no successor gets created. That is the first halt condition, and it matters because building the successor first quietly turns “complete the migration” into the goal.
Case 1: a scheduled task’s existence is not its destination
The first rotation stopped on a scheduled task. It existed. It was enabled. The configuration name matched. By those signals, it had carried over.
The thing to check was where its results land. OpenAI documents two modes: a scheduled task in a chat returns to an existing chat on a schedule, and a standalone scheduled task starts a new chat for each run and reports into Scheduled.
These are different tools. Leave something standalone when you expected a long-running task to continue in one place, and the run succeeds while the operation splits in half. Push an intentionally independent run back into an existing chat, and you inherit context you did not want.
So each scheduled task got these added to the snapshot: in-chat or standalone; who receives the result; the current destination; whether duplicate configurations exist; and whether the intent still holds after the switch.
My environment uses internal type names for this, but those are local implementation vocabulary. The generalizable part is the in-chat versus standalone distinction in the official docs.
Case 2 and 3: an acknowledgement needs a subject and a timestamp
The second rotation had an unread handoff outstanding. The role transferred. The next action was written down. But a request that arrived just before the switch had never been acknowledged, so the successor could not start from the correct position.
The third had an acknowledgement — for the state before the switch. After changing the reference, you have to ping the successor again and have it confirm that it is the current reference. Without that fresh ping, “the successor I created could read this” and “requests made after the switch reach the successor” get conflated.
Acknowledgement is now two stages:
- Direct ACK — before the switch: required docs, role, configuration, open items, and closure of external operations.
- Route ping — after the reference changes: current generation, pending requests, scheduled tasks, waiting conditions.
The point is not to archive acknowledgement text. It is to pin down what was acknowledged, and as of when.
Independent QA turns a task into a switchover
Prepare it yourself, build the successor yourself, switch it yourself — then judge completion yourself, and you simply retrace the assumptions you made during preparation.
Notice what actually went wrong across the three cases: the delivery destination, the unread handoff, and the stale ACK were all individually successful operations. What failed was the connections between them.
Independent QA walks it in order:
- Is the current reference the successor?
- Do scheduled task modes and destinations match the contract?
- Are pending handoffs neither dropped nor double-executed?
- Can the successor explain its role, prohibitions, open items, and next action?
- Is there a snapshot that survives retiring the old task?
- Did any external operation start mid-migration?
On REWORK, the old task stays. Fix the gap with the reference still reversible. Retire it only after PASS.
Deletion comes last, and only after retirement
codex delete is documented as a stable command that permanently deletes a saved interactive session by ID or name. It is not a rollback operation.
So irreversibility gets confirmed before the command runs. Reference switched to the successor, scheduled tasks verified, pending handoffs cleared, direct ACK received, fresh ping received, independent QA passed, old task retired — then one target, specified individually, through the official path.
Bulk deletion and direct editing of local data are not part of this procedure. Afterwards: an environment health check, and a final receipt confirmation from the managing side to the successor. That is when a rotation is complete.
Three cases, three different gates
| Case | Gap found | Gate added |
|---|---|---|
| Role task A | Scheduled task existed, but its result destination was ambiguous | Snapshot in-chat vs standalone and the expected recipient |
| Role task B | Completed and unread handoffs were mixed together | Check unprocessed items per delivery; block double execution |
| Role task C | A pre-switch ACK was nearly treated as post-switch delivery confirmation | Separate direct ACK from fresh ping |
For role tasks with no automations, I recorded “zero” as a contract in its own right, so that migrating does not become an excuse to add scheduled tasks.
I did not total the disk savings across the three cases. Codex-wide history and other tasks were changing over the same period, so no figure here can be attributed to rotation alone.
The order, and why it is the order
Preparation audit → metadata snapshot → successor built without duplicating history → direct ACK → reference switch → fresh ping → independent QA → retire old task and official delete → health check and receipt.
The arrows do not commute. Create the rollback point before the successor. Confirm the successor’s understanding before the switch. Confirm delivery after the switch. Do not delete the old task before independent QA.
Leaving yourself places to stop mattered more than the mechanism did.
Try it on something unimportant first
- Can the documents of record alone explain the role and its prohibitions?
- Are complete, incomplete, and next-action separated?
- Are there no external operations mid-flight?
- Is there a snapshot you can return to?
- Did you check where scheduled task results go, not just that they exist?
- Did you separate unread handoffs from completed ones?
- Did you receive a direct ACK from the successor?
- Did a fresh ping arrive after the switch?
- Did someone else’s perspective run QA?
- Is the official delete used only after retirement?
- Did you confirm the post-delete health check and receipt?
Start with a small, unimportant task that has no scheduled tasks and no external operations. I did not hit the same failure three times — the first showed me destinations, the second unread handoffs, the third acknowledgement freshness. Each attempt added a gate.
Rotating a long-running agent thread was never about moving an old conversation into a new box. It was about putting the decisions worth keeping into the record, handing the successor only the current state, and having someone else confirm it arrived.
References
Official documentation was verified on July 20, 2026 and re-checked for this English version in September 2026.