1.0.81: session restore auto-continues work the user aborted, trapping loop-prone models

Summary

The interrupted-session restore added in 1.0.81 tracks a per-session working flag in ~/.copilot/open-sessions-state.json. The flag is set on assistant.turn_start and cleared only on session.idle (natural completion) or explicit session close. User abort does not clear it.

On a plain startup in the same directory, any session still flagged working is restored without confirmation and the CLI auto-enqueues this prompt:

"This session was interrupted while you were working. Review what you had done, then carry on and finish the task you were on." (displayed as "Continue the work that was interrupted.")

Sessions not flagged working go to an interactive picker instead, which is what the changelog's "offers to restore" describes.

For loop-prone models (small local BYOK models, thinking models), the result is unescapable: the model loops, the user aborts, the user restarts the CLI, the continue prompt is auto-sent, the model resumes the same stuck turn. Every restart repeats the cycle.

1.0.81 code (app.js)

Auto-enqueue, fje, called for sessions in the wasWorking set; the rest go to the picker:

var WJr="This session was interrupted while you were working. Review what you had done, then carry on and finish the task you were on.",
    jJr="Continue the work that was interrupted.";
function fje(e){e.send({prompt:WJr,displayPrompt:jJr,mode:"enqueue"})...}
...
if(J.has(x.session.sessionId)&&fje(x.session),!E)throw new Error("Interrupted-session recovery is unavailable");
await E(x.sessionIds,x.offeredSessionIds)

Tracker — set on turn start, cleared on idle or close, no abort handler:

noteTurnStarted(t){this.setWorking(t,!0)}
noteSessionIdle(t){this.setWorking(t,!1)}
noteSessionClosed(t){this.open.delete(t)&&this.enqueue(()=>OX(this.filePath,t,void 0))...}

Kill switch: COPILOT_TEST_DISABLE_INTERRUPTED_SESSION_RESTORE=true

Changelog 1.0.81: "Startup now offers to restore sessions that were still open when their CLI went away, so a crash or a machine restart no longer means reopening each terminal by hand."

Evidence

Session 256b3414-9156-47e3-95b1-516d66847a42, BYOK qwen-27b via llama.cpp.

The 8.2 h loop (1,509 calls, 117M input tokens, no gap over 5 min, every call finish_reason: tool_calls) ran on 1.0.80. The looping is a property of the small model; 1.0.81's contribution is making it unescapable:

UTC, Aug 29	Event
02:24:56	1.0.80 process exits mid-turn
02:47:45	1.0.81 startup restores the session (session.resume)
02:48:00	User types "continue"; loop resumes
06:20:34	User aborts (abort, reason: "user_abort")
06:24:18	Shutdown
06:26:21	Restart
06:26:28	Continue prompt auto-injected
06:26:32	User exits (25 s)
06:27:43	Restart
06:28:02	Continue prompt auto-injected again
06:44:36, 06:51:21	Two more user aborts
06:53:21	Shutdown

Session total: 2,949 model calls, 217M input tokens over 20 turns.

TUI during the loop — the model's degenerate repetitive output fills the screen:

Suggested fixes

1. Clear working on user abort. Aborting is an explicit signal that the current work should not be resumed.
2. Require confirmation before enqueuing the continue prompt, or queue it as an editable draft instead of a sent message.
3. Stop auto-continuing the same session after N restarts.

Workaround

Set COPILOT_TEST_DISABLE_INTERRUPTED_SESSION_RESTORE=true.

Secondary bug (1.0.81, BYOK): utility model calls 404

Auto-mode utility calls send the internal model id to the local endpoint instead of the BYOK model name:

model.turn_failed 2026-08-29T04:47:33
  model: gpt-5.4-nano  (modelInfo: {id: "gpt-5.4-nano", name: "qwen-27b"})
  error: 404 The model `gpt-5.4-nano` does not exist.

The failing call is the side-channel prompt "Task: Detect whether the CURRENT MESSAGE expresses frustration with an AI coding assistant...". 4 occurrences on Aug 29; the turn recovers after each failure. Related: #4445 (auto mode picks unavailable models).

Related issues

• #4668 — interrupted create_session resumes ~1.6 h later, duplicating work (same theme, different mechanism)
• #4639 — event storage exhaustion drives compaction loop/OOM (I saw its 409 session_event_storage_exhausted warnings in the same session)

Versions

1.0.80 fine. 1.0.81 regresses. 1.0.82 unchanged (same restore code, no changelog entry).

Commencez dans app.js avec le chemin de restauration des sessions interrompues, la vérification de wasWorking et les méthodes du tracker noteTurnStarted, noteSessionIdle et noteSessionClosed. Reproduisez le comportement en utilisant l’état de session dans ~/.copilot/open-sessions-state.json, puis vérifiez qu’une session interrompue par l’utilisateur n’est pas automatiquement reprise au démarrage suivant. Vérifiez le coupe-circuit COPILOT_TEST_DISABLE_INTERRUPTED_SESSION_RESTORE pendant les tests.