Feature: true resumable coding_loop runs after hitting max_iterations (not just re-running on leftover files)

[proagentstore]

When a coding_loop_start run hits max_iterations (or otherwise stops without completing), there is currently no real 'resume' — only the option to start a brand new run against the same repo. Today that new run happens to see whatever uncommitted files the previous run left in the working tree on disk, so if the prior run got partway through editing a file before stopping, a new run can stumble onto that leftover diff and build on it. But that's incidental: it depends entirely on git not having discarded anything, and the new run has none of the previous run's actual reasoning, iteration history, or context for WHY it made those changes or what it still intended to do. If the working tree were clean, or another run had touched the repo since, there would be nothing to pick up at all.

Requested feature: genuine resumability for a run that hit its iteration ceiling (or failed for a recoverable reason).

1. When a run stops at max_iterations, keep its full session/reasoning context addressable (not just the code artifacts on disk).
2. Give the owner a way to review why it stopped — what it had completed, what it was mid-way through, what it still intended — before deciding what to do next.
3. Allow the owner to then choose: (a) reset and start clean, (b) resume the same run with its prior context intact, optionally adding new instructions/info/ticket updates without losing what it already figured out, or (c) resume as-is with more iterations granted.
4. This should work even hours later — the point is a human can check back on a stalled run on their own schedule, add clarifying info or a course correction, and let the agent continue rather than re-deriving everything from scratch each time.

This came up today (2026-09-12) while retrying issue #150 on proappstore-online/platform: a run died on a relay timeout at iteration 4 of 20 with a good partial fix already written but uncommitted. A second run happened to build on that leftover diff successfully, but only by chance — it had no actual memory of the first run's reasoning, and a true resume would have been far more reliable.

[serge-ivo]

Slice 1 shipped in 1ee023c6: a run that stopped at max_iterations now tells its successor what already landed. Items 1–3 are NOT done; they need a design decision (below).

What existed before

#523 (7cae041a) already gives a new coding run a resume note: pendingCodingResumeNote (lib/coding-resume-note.ts), injected as goal.resumeNote at workflows/coding-session.ts:733. It lists the acts the previous run on the same session observed to land, built from agent_events. But the gate was

lib/agent-loop-store.ts:298	if (row?.stop_reason !== "interrupted") return null;

and a Pilot that uses up its step budget ends max_steps → max_iterations (lib/coding-pause.ts:270). So the case this issue describes got no note.

What changed

The gate is now "did the run reach a verdict on its objective". RESUMABLE_STOP_REASONS lists the endings that did not:

stop reason	briefed?	why
interrupted	✅ (unchanged)	the platform cut it off (#546)
max_iterations	✅ new	step budget spent mid-work (this issue)
engine_limit	✅ new	the coding CLI's usage window outlasted the run's wait (#541)
provider_credit	✅ new	balance ran dry; #773's own sentence says "start the run again" after topping up
failed	❌	the run gave its verdict; repeating its steps may be right
escalated	❌	the run asked a human, answered through its own handoff
cancelled	❌	a human's choice, possibly this issue's option (a) "start clean"
done / no_progress / budget	❌	a verdict, or not something a restart should inherit

The note's first line now states the true cause per stop reason. A step-limited run is not told it was "interrupted by the platform". The interrupted wording is byte-identical and pinned by a test. The note is still immediate-predecessor-only, with a 6-hour lookback.

Verified: 17 new tests in coding-resume-note.test.ts, 20 → 37. (The commit message says 22 → 37; 20 is correct.) Restoring the old gate fails 3 of them. Full suite 11,409/11,409, both API typechecks, biome and the static guards are clean.

Not verified:

• No live run observed. It needs a run that hits max_iterations followed by a new run on the same session.
• Session reuse not traced. I did not confirm that coding_loop_start re-uses the session a stopped run was on. The note is keyed on session_id; a fresh session gets no note.
• The Agent work as first-class Tickets — granular, with reasoning + per-ticket conversation #150 trigger's stop reason not traced. I haven't established which stop reason the "relay timeout" in Agent work as first-class Tickets — granular, with reasoning + per-ticket conversation #150 recorded. If it was failed, this slice does not cover it.

What this does NOT cover

• The Agent work as first-class Tickets — granular, with reasoning + per-ticket conversation #150 example itself. The note lists acts recorded in agent_events (pushes, PRs, merges). Uncommitted edits in the working tree are not acts, so a partial fix written but not committed is still carried only by the files on disk, exactly as this issue describes.

• Items 1–3 need an owner decision, not a follow-up commit:

  1. "Keep its full session/reasoning context addressable." This contradicts A 2-hour run that closed ten issues and pushed 15 times is reported as "outcome: failed" with a Wrangler docs link — the Cloudflare subrequest ceiling is relayed raw as the objective failing #523's recorded choice of option (b), "checkpoint the OBJECTIVE, not the transcript". The coding-resume-note.ts header explicitly rejects persisting the Pilot's reasoning (actionLog/transcript are function-local in coding-loop.ts) and refuses to state "what remains", because the platform cannot know it.
  2. A review surface ("what it completed, was mid-way through, still intended"): console UI, and "intended" has the same problem as item 1.
  3. Reset / resume-with-context / grant-more-iterations: a run-control API and UI.

  Suggested split for pags-ba:

  • (i) the item-1 decision (persist the transcript, or keep option (b));
  • (ii) a "grant more iterations and continue" action, which needs no transcript if (b) stands;
  • (iii) carrying uncommitted working-tree state into the note, e.g. a git status / diff summary captured at stop.

Leaving this issue open.

[serge-ivo]

The resume note (#523, and slice 1 here) never reached an agent-started run's successor. Fixed in f8ded1bb.

The slice-1 comment listed "Session reuse not traced" as unverified. I traced it, and the note was keyed on something the successor usually doesn't have.

The bug, verified in code

1. The lookup matched on session. lastUnfinishedRunForSession queried agent_loop_runs … WHERE … session_id = ?3, with the new run's own sessionId (workflows/coding-session.ts:733).
2. Agent-started runs open their own session. That covers delegate_goal, start_work, the Loop button and coding_loop_start. With no active session, ensureSession creates one and returns opened: true (lib/coding-session-open.ts:463-498), which becomes sessionOpenedByRun: opened (lib/loop-drivers.ts:334).
3. A run-opened session is closed when the run ends. shouldEndSessionAfterRun({ openedByRun }) leads to endSession(..., status), with status "error" for failed/max_steps (workflows/coding-session.ts:954-971).
4. So the next run opens a new session. getActiveSessionForRepo only matches status = 'active' (lib/coding-store.ts:396). The lookup then ran against a session with no history and returned null, so no note.

The note only ever reached runs on a session a human opened, since those outlive their runs. #523's own incident was a delegated run cut off after 15 pushes whose session ended status: error: exactly the case the note couldn't reach.

The fix

• Lookup: lastUnfinishedRunForRepo joins agent_loop_runs to coding_sessions and matches the repo of the caller's session, looked up within the caller's own user and instance.
• Unchanged: the rest of the logic. It still takes the newest finished run and then judges it (immediate predecessor only), with the 6-hour lookback and RESUMABLE_STOP_REASONS. The workflow call site is untouched.
• Wording: the note now says "a previous run on this repository", not "on this session". The predecessor is usually on an earlier session, so the old wording pointed the model at history that isn't there. The test pinning the interrupted sentence moved by that one word, on purpose.

Verified

• coding-resume-note-repo.test.ts, 6 new tests against the real migrated schema (d1-sqlite), run end to end through pendingCodingResumeNote:
  • Run A opens S1 on repo R, lands a push, stops at max_iterations, and S1 is closed as error. Run B on new session S2 of R gets the note, and it names the push.
  • A session on a different repo gets nothing.
  • A done run on any session of R in between ends the note's job.
  • The caller's own unfinished run is skipped, and A is still found.
  • Another user's session id resolves to no repo.
  • The 6-hour floor holds.
• Mutation-checked:
  • Restoring the session-keyed query fails 2 tests, including the A → B case.
  • SELECT * in place of r.* fails 2: the join's own status/started_at would overwrite the run's.
• Suite: full suite 11,477/11,477; API typecheck (source and tests), biome and the static CI checks are clean.

Not verified

• No live run. That needs an agent-started run stopped for a resumable reason, followed by a new run on the same repo.
• Whether the end step runs when the Workflow itself is killed, not caught. If it doesn't, the idle reaper still closes the session, and the fix covers that case the same way.

Noted, not changed

• Acts are read instance-wide. actsInWindow filters by instance and time window (lib/instance-work.ts:400-404), not by repo. If another repo's run on the same instance overlapped run A's window, its acts would appear in the note. That predates this fix.
• Owner decisions are unchanged. Items 1–3 above still wait on the owner, as does A 2-hour run that closed ten issues and pushed 15 times is reported as "outcome: failed" with a Wrangler docs link — the Cloudflare subrequest ceiling is relayed raw as the objective failing #523's approval of option (b).

[serge-ivo]

Run 6ae2f583 continuation — bookkeeping

Two slices from the prior run are now on main. CI and Deploy API Worker both passed on f8ded1bb.

Commit	What it does
1ee023c6	The resume note now reaches runs that stopped at max_iterations, engine_limit and provider_credit, not just interrupted. It also states the real stop reason.
f8ded1bb	The previous run is now looked up by repo, not by session, so a run started by an agent (which opens a new session) receives the note.

Waiting on an owner decision

• (i) Save the stopped run's reasoning, or keep A 2-hour run that closed ten issues and pushed 15 times is reported as "outcome: failed" with a Wrangler docs link — the Cloudflare subrequest ceiling is relayed raw as the objective failing #523's option (b). Option (b) is "checkpoint the objective, not the transcript", and it is what coding-resume-note.ts implements today. Items 1 and 2 of this issue (keep the context available, review what the run intended) depend on this choice.
• Item 3(b), "resume the same run with its prior context intact". This depends on (i).

Buildable without an owner decision

• (ii) "Grant more iterations and continue" (item 3(c)): new API plus console UI. It needs no transcript if option (b) stands.
• (iii) Carry the stopped run's uncommitted changes into the note. Backend only. Two things to know:
  • codingResumeNote returns null when no action landed (lib/coding-resume-note.ts:113, if (!landed.length && !unobserved.length) return null;). A run that left only uncommitted edits, which is the Agent work as first-class Tickets — granular, with reasoning + per-ticket conversation #150 shape, gets no note today, so that check has to change too.
  • At run start the successor already gets a count of uncommitted files, unattributed, via the REPOSITORY STATE instruction (workflows/coding-session.ts:700-704, readRepoWorkingState → dirtyClause). That instruction says "You did not create this state". A note that attributes the same files to the previous run needs to agree with it.
• Item 3(a), "start clean": not split out. Today this is close to cancelling and starting a new run. cancelled is not in RESUMABLE_STOP_REASONS, so that new run gets no note.

Not verified / not filed

• Agent work as first-class Tickets — granular, with reasoning + per-ticket conversation #150's stop reason: not traced. If the relay timeout was recorded as failed, it is outside RESUMABLE_STOP_REASONS and (iii) would not reach it either.
• actsInWindow reads actions across the whole instance (lib/instance-work.ts:400-404), not by repo. Noted in the comment above; not filed as its own issue.

No further code was written in this continuation run; its objective was verification and bookkeeping only.

[serge-ivo]

Run 199ec11f continuation — bookkeeping

One gap noted in the previous bookkeeping comment has since been resolved.

Closed: actsInWindow instance-wide scoping

The previous comment noted under "Not verified / not filed" that actsInWindow reads acts across the whole Coder instance rather than scoping to the run's session. That was filed as #809 and fixed in cda8ef91 (merged 2026-09-13). CI passed. The lookup is now scoped to the run's session.

Still open

Waiting on an owner decision:

• (i) Save the stopped run's reasoning, or keep A 2-hour run that closed ten issues and pushed 15 times is reported as "outcome: failed" with a Wrangler docs link — the Cloudflare subrequest ceiling is relayed raw as the objective failing #523's option (b) ("checkpoint the objective, not the transcript"). Items 1 and 2 of this issue depend on this choice.
• Item 3(b) "resume the same run with its prior context intact" depends on (i).

Buildable without an owner decision:

• (ii) "Grant more iterations and continue" — needs a new API plus console UI.
• (iii) Carry the stopped run's uncommitted working-tree changes into the resume note. Backend only. The return null at lib/coding-resume-note.ts:113 must change, and the note must agree with the REPOSITORY STATE instruction at workflows/coding-session.ts:700-704.
• Agent work as first-class Tickets — granular, with reasoning + per-ticket conversation #150's stop reason has not been traced yet.