Claude Code 2.1.288 background command limits: poll Sume jobs

Claude Code 2.1.288 applies the background command limit only to unattended sessions (-p, SDK, CI, cloud). How to poll a Sume job so a -p run keeps it.

5 min readSume
All posts

Claude Code 2.1.288 changed the background command time limit so it applies only in unattended sessions: -p, the Agent SDK, CI and cloud. In a terminal, desktop or VS Code session there is no limit. If you start a Sume render from claude -p or CI, do not park the wait in a background command. Save the job id, poll with jobs_wait in slices of up to 55 seconds, and let a later run read the result.

What the changelog says

The Claude Code changelog entry for version 2.1.288, dated October 2, 2026, says the background command time limit now applies only in unattended sessions (-p, Agent SDK, CI, cloud), and that terminal, desktop app and VS Code sessions have no limit. The same release makes hung LSP tool calls time out after 60 seconds. I read the entries, not the source, so I do not state the numeric background limit; the entry does not give one.

Interactive vs unattended

A render is a durable Sume job. It keeps going when your shell command, your session or the whole machine goes away; see Jobs and results for statuses and result reads. What differs by session type is whether your waiting process survives.

Where to wait for a Sume job (read 2026-10-04)
SessionBackground command limitSafer wait
Terminal, desktop, VS CodeNone, per 2.1.288Background watch is fine
claude -pAppliesjobs_wait slices in the foreground
Agent SDKAppliesPersist the job id, resume next run
CI or cloud sessionAppliesSeparate poll step keyed by job id

A pattern that survives the limit

  • Submit with an idempotency_key and write the returned job id to your own store before doing anything else.
  • Wait with jobs_wait in slices of 45 to 55 seconds, the range Sume's MCP guidance uses (the MCP tools and gates page shows the same 5 to 55 second bound on script_run). Loop in the foreground while the status is queued or processing.
  • If the session is about to end, stop and exit cleanly. Do not cancel: the job continues.
  • On the next run, call jobs_status for each stored id, then jobs_result for completed ones.

Mistakes to avoid

Do not resubmit because a wait ended. A retry with a new key is a second paid job; reuse the same key only for an exact retry of a failed request. Do not treat a killed background process as a failed render either: check jobs_status first.

If your CI tool needs a hard time budget, give the poll step its own timeout and a clear exit code for still running, separate from failed. The MCP quickstart shows the read-only calls you can use to inspect state without spending.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume