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

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.

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.