Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug]: Pi auto-continuation pauses silently on any non-injected prompt (including post-compaction context) — only /loopx resume re-arms it

Aperta
  • Qualcosa non va?
#6,107 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript, typescript
Ambito
ai-infra-agents

Direzione di ricerca

Start in loopx/pi_goal_mode/pi-goal-loop-runtime.mjs at userPrompt (around line 1076), where any prompt that differs from lastInjectedPrompt sets autoResume to false and cancels the schedule without notifying. Compare it with interrupt() (around line 1097), which does notify, and with the before_agent_start hook in loopx/pi_goal_mode/index.ts (around line 619). Done means host-generated prompts such as compaction or queued work no longer silently disarm the loop, or the pause is at least surfaced. The issue offers several fix options, so confirm the approach with the maintainer before writing code.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Pi auto-continuation pauses silently on any non-injected prompt — including Pi's own post-compaction context — and only /loopx resume re-arms it

Affected version: Pi surface installed from release 20261010T034436Z; the userPrompt/interrupt logic quoted below is identical in this repository at 0233a2f32 (loopx/pi_goal_mode/pi-goal-loop-runtime.mjs, loopx/pi_goal_mode/index.ts).
Host surface: pi (Pi visible goal loop)
Impact: a long-running Pi goal loop is disarmed by any prompt that is not the loop's own injected task body — including Pi's post-compaction context message and other system/queued work. The disarm is silent (no notification, no pause reason surfaced), the host looks healthy (loopx status clean, LoopX keeps reporting should_run=true), and every subsequent step then needs a human message. Recovery requires the owner to know about /loopx resume.

Code involved

// loopx/pi_goal_mode/pi-goal-loop-runtime.mjs:1076
async userPrompt(key, prompt) {
  ...
  if (!binding || binding.terminal) return
  if (String(prompt || "") !== binding.lastInjectedPrompt) {
    const expected = { generation: binding.generation || 0, goalId: binding.goalId }
    const committed = await services.store.write(key, { autoResume: false }, expected)
    if (!committed) return
    if (disposed || epoch !== instanceEpoch) return
    cancelScheduled(key)          // <- no notify() on this path
  }
},

// loopx/pi_goal_mode/index.ts:619
pi.on("before_agent_start", async (event, ctx) => {
  const { key } = bindContext(ctx)
  await loop.userPrompt(key, String(event.prompt || ""))
})

Compare with the abort path, which does tell the user what happened:

// pi-goal-loop-runtime.mjs:1097 (interrupt)
services.notify(`LoopX goal ${committed.goalId} auto-continuation paused after abort; run /loopx resume to continue.`, "info")

The loop does correctly recognize its own turns (lastInjectedPrompt is set to the task body before the prompt is sent), so injected auto-continuation turns do not disarm it. The problem is everything else that reaches before_agent_start.

Observed behaviour

  • Session: one long-lived Pi session (cwd = the goal's project); the LoopX goal was armed and the loop ran for hours.
  • A Pi context compaction was recorded in that session's transcript at 2026-10-10T07:44:38Z.
  • Afterwards the durable bridge state was:
{ "autoResume": false, "terminal": false, "generation": 1,
  "sessionKey": "2026-10-10T05-49-04-788Z_01a1245b-9794-71a9-9f76-bc39a6a15eadcb34" }

i.e. a pause, not a lost binding — sessionKey(process.env.PI_SESSION_FILE) reproduces that key exactly, and store.read(key) resolves.

  • From that point on the loop produced no turns: every step required a human message. Nothing was shown in the UI.
  • The LoopX side was never the blocker: quota should-run kept returning decision: run / should_run: true, scheduler_hint.action: run_now, cadence_class: active_work, must_attempt: true.
  • Writing autoResume: true back into that same state file (what /loopx resume does) re-armed the loop.

Why this is a defect rather than intended behaviour

A pause on user input is a reasonable design (the owner takes the wheel; explicitly re-arm afterwards). But:

  1. Pi's own automated context work (compaction, recovery, queued work — see docs/extensions.md: "Automatic retries, recovery, compaction, or queued work can continue afterward") is indistinguishable from user input at this event, so the loop is disarmed by the host's own housekeeping.
  2. The pause is silent, unlike the abort path which notifies. The user sees a healthy session and a stalled goal.
  3. Nothing durable records why it paused, so neither the user nor a diagnostic tool can tell "paused by input" from "never armed".

Suggested fixes (any of these)

  1. Do not treat host-generated prompts as user input. before_agent_start exposes the prompt plus structured systemPromptOptions, and the transcript records a compaction entry; use whichever signal is reliable to recognize compaction/recovery/queued runs and skip the disarm for them.
  2. Notify on this path, mirroring interrupt(): e.g. "LoopX goal auto-continuation paused by input; run /loopx resume to continue."
  3. Persist a pause reason (e.g. pauseReason: "foreign_prompt" | "aborted") in the bridge state so /loopx status and the host loop can surface it.
  4. Optionally auto-re-arm when the interrupting prompt was not user-authored.

Reproduction recipe

  1. Arm a LoopX goal in a Pi session and confirm one auto-continuation round.
  2. Trigger Pi context compaction (or send any manual message).
  3. Observe .loopx/pi/<sessionKey>.json flip to autoResume: false with no UI notification, and no further automatic turns, while LoopX continues to report run_now / must_attempt: true.
Lingua principale
Python
Stelle
6.2k
Fork
596
Merge medio
5h 34m
PR unite (30g)
931

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di loopx-project/loopx

Tutte le issue di loopx-project/loopx

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.