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.

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.
| Endpoint | Use |
|---|---|
| GET /v1/jobs | List jobs, filterable by status and type. |
| GET /v1/jobs/:id/status | Lightweight status read for polling. |
| GET /v1/jobs/:id/result | Result after completion, with public artifact URLs. |
| GET /v1/jobs/:id/events | Public 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.
queuedandprocessingare normal and non-terminal; keep waiting.completedmeans the result is ready; fetch it once.failedcarries a public error; read it from the job record.canceledis 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
eventsbefore assuming it is lost. - Never resubmit a paid request because a transcript is missing.
Sources
Related posts
More in Developers
- Computer-use agent or API call: use Sume jobs, not clicks
OpenAI added computer use to its Agents API on Sep 29, 2026. For media generation, an agent should call Sume's API or MCP tools rather than click a dashboard.
- Join two generated tracks without a gap: timeline audio concat
One Lyria generation too short? Join up to 20 Sume-hosted audio files into one gapless wav with timeline audio concat and read segment offsets.
- Video model aliases from config that fail at boot, not at submit
Map your own names like hero-clip to Sume model ids in config, then check each against GET /v1/video-router/models at startup so a retired id stops the deploy.
- Container snapshot restore: resume a Sume job from its job_id
Cloudflare Containers can snapshot a running container. Save the Sume job_id in it, and after a restore read the job's status_url instead of resubmitting.
Written by Sume