Codex 0.160 agent history 'Show more': recover Sume jobs by job list

Codex CLI 0.160.0 adds Show more pagination to agent command center history. If a thread scrolls away, Sume's GET /v1/jobs list still holds every job.

4 min readSume
All posts

If a long Codex run has scrolled out of view, the job list is the place to recover Sume work. Codex CLI 0.160.0 (2026-10-01) added Show more pagination to the agent command center history, but a Sume job does not depend on any chat history: GET /v1/jobs lists the workspace jobs your key can read.

The Codex changelog also lists opt-in Guardian review and Windows sandbox fixes in the same release.

Recovering by job list

The API reference describes GET /v1/jobs as listing workspace jobs, filterable by status and type. The single-job reads are GET /v1/jobs/:id, /status, /result and /events.

Job endpoints for recovery (read 2026-10-03)
EndpointUse
GET /v1/jobsList jobs, filterable by status and type.
GET /v1/jobs/:id/statusLightweight status read for polling.
GET /v1/jobs/:id/resultResult after completion, with public artifact URLs.
GET /v1/jobs/:id/eventsPublic timeline for debugging and recovery.

Who can see what

Visibility has a rule worth knowing before you look for a missing job. An API key reads the jobs its own member created in the key's workspace. A job made under another member's key is 404 not_found, even in the same workspace.

A Studio Agent turn reads every job in the thread it runs on. Everything else is a 404: other workspaces, other members' jobs in other threads, and any job a key's member did not create. A thread_id filter narrows a list but never widens what a key can read.

Statuses to filter on

A recovery pass usually wants the jobs that have not finished, and then the ones that finished while you were away.

  • queued and processing are normal and non-terminal; keep waiting.
  • completed means the result is ready; fetch it once.
  • failed carries a public error; read it from the job record.
  • canceled is terminal and was requested earlier.

Make recovery unnecessary

The cheaper habit is to write the job id somewhere durable at submit time. The docs say to store the job id from submit responses so an integration can recover work after process restarts, and to store status_url, result_url, events_url and cancel_url when present.

Also keep the Idempotency-Key you used. If a run died between sending the submit and saving the response, repeating the submit with the same key returns the original job instead of billing a second one.

A resume routine

  • List jobs with a non-terminal status and match them against your saved ids.
  • For each, read status; wait or fetch as needed.
  • For anything you cannot match, check events before assuming it is lost.
  • Never resubmit a paid request because a transcript is missing.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume