Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#6,107 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, typescript
Área
ai-infra-agents

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Python
Estrellas
6.2k
Forks
596
Merge medio
7 h 35 min
PR fusionados (30 d)
928

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de loopx-project/loopx

Todos los issues de loopx-project/loopx

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.