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
- Cursor Security Review bot on a Sume webhook handler: what to find
Cursor added a Security Review bot on Sep 23. A webhook handler for Sume should pass seven checks: raw body, timestamp window, rotation, empty secret and more.
- Cursor self-hosted machines can't take Sume webhooks on a private URL
Sume rejects localhost, private-network and non-HTTPS webhook URLs. An agent on a self-hosted machine should poll status_url or use a public HTTPS receiver.
- Demand Gen copy limits: 40-character headlines, one at 30 or fewer
Demand Gen allows 40-character headlines (one must be 30 or fewer), 90-character descriptions and 10-60 second videos. A checker script plus the Sume lengths.
- Design a render tool for a stateless MCP server: job ids as arguments
MCP 2026-07-28 removes protocol sessions. A render tool stays correct if its state lives in a job id the client passes back, as Sume jobs do.
Written by Sume