Codex background tasks keep their turn's permissions: paid Sume calls

A Codex background task inherits the permissions of the turn that created it, so a Sume render you approved in one turn can keep running paid calls later. The Codex changelog for 0.161.0, October 7, 2026, says background tasks retain originating turn permissions. Sume's tools hide write and paid tools until the session has mcp:write or an API key, so the permission you carried into the task was the one that mattered.

This is good news for predictability and a reason to be careful about what you approve first.

What carries over

Rows one and two are from the Codex changelog; the rest from Sume's gates.

Steps before you hand off a long task

Write the cap into the instruction: each paid Sume call needs an idempotency_key and a max_spend_usd, and the agent must call the preview first with dry_run=true. Then limit the batch: name the number of renders in the task. Finally, decide how you will check back. jobs_list shows jobs on your account, and balance_get shows what is left.

• Use an OAuth session without Write for the planning step, then reconnect with Write for the render step.
• Prefer a small test wallet when you try a new task shape.
• If a task is wrong, stop it and call jobs_cancel on any job still queued; check Sume's docs for when a cancel is accepted.

Writing the first turn well

The first turn is where the risk is set. If you answer an approval prompt with a broad yes because you want to move fast, the background task keeps that yes. Prefer approving one named tool at a time, such as the preview call, and approve the paid call separately once you have read the estimate.

If you use an API key instead of OAuth, remember that the key itself carries the full tool set whatever the turn approved; the turn permissions are then your only brake on the Codex side. A key scoped to a small test wallet is the second brake.

What Sume does not do

Sume does not look at the Codex task or its permissions. A job already running is not undone by stopping the task. And because max_spend_usd applies only when you send it, a task that omits it has no per-call ceiling beyond your wallet.