Codex keeps your computer on reconnect: find Sume jobs first

After a Codex task resumes on a computer that was offline, check Sume before you ask for the clip again. Sume jobs are durable, so one submitted before the gap probably still ran. Call jobs_list, find the job by its idempotency_key or purpose, and wait on it with jobs_wait instead of paying twice.

The Codex changelog (read 2026-10-07) lists, under 0.161.0 on Oct 7, that new tasks keep your selected computer while it reconnects or is offline.

What the release note says and does not say

The note says that new tasks keep the selected computer while it reconnects or is offline. It does not say what happens to a tool call that was in flight. Treat that as unknown and design for both outcomes: the call was never sent, or it was sent and the answer was lost.

Why Sume can be re-asked safely

Every Sume write and paid tool needs an idempotency_key. The same key with the same payload returns the original job instead of creating another. So the safe recovery is to resend with the same key, not a fresh one. A different payload under the same key is a conflict.

Keep the key where the next task can read it

Write the key in the repo or task notes before the call. A short line such as the purpose and the key is enough. When the task resumes, the first step becomes: read the notes, check the job, then continue.

Do not write an API key there. Read it from an environment variable on the selected computer.

What to log before each paid call

Write one line to your task notes before the call: the purpose, the idempotency_key and the time. After the call returns, add the job id. This costs a few seconds and makes every later recovery a lookup. It also gives you a clean record when you review spend, because each line maps to one job.

Waiting without a timeout

jobs_wait returns in slices of up to 55 seconds on the remote server, with a default of 50. Loop it until the status is terminal. Codex's own tool timeout defaults to 60 seconds in its config docs, so a 50-second slice stays inside it.

If the computer drops mid-wait, the next task simply starts the loop again from the job id.

For wallet safety, call balance_get after a long gap and compare it with your notes. A drop larger than you expect is a sign that a resend created a second job, and jobs_list will show it.

If you find an unwanted duplicate that is still queued, cancel it with jobs_cancel, which needs its own idempotency_key.

Keep the notes file short and dated so the next task can read it quickly.