/loop wake-up fires with stale prompt referencing work that doesn't exist
Summary
A scheduled /loop wake-up fired with a continue: prompt referencing a "DSPy heavy run", a process PID, and /tmp/dspy_optimize.log — none of which existed on the host. No prior turn in the resumed session had set up that work. The agent then chased the phantom task: searched for the log, attempted to SSH to a remote host to verify, and fabricated a plausible-sounding explanation of what the run was for when the user asked.
Impact
- Wastes user time (user has to disprove the agent's confident-but-unfounded framing)
- Erodes trust — the agent looks like it's hallucinating ongoing work
- Hard to detect from the user side: the wake-up prompt is authored by a prior session, so the current session has no way to know it's stale
Likely cause
/loop in dynamic mode passes the same prompt verbatim to the next firing via ScheduleWakeup. If the prior session encoded session-specific state into that prompt ("check if X is done"), later firings re-execute that prompt with no validation that X was ever real. AND across context compaction the loop-state referenced by the prompt may have been dropped from the summary.
Suggested mitigations
- When a
/loopwake-up fires after compaction, surface the loop prompt to the agent with a "this is a scheduled continuation from session<id>, not a fresh user turn" tag so the agent treats unverifiable claims with skepticism. - Encourage
/loopskill authors to write prompts in terms of verifiable filesystem/process state ("if/tmp/foo.logexists AND contains X") rather than narrative ("the heavy run from earlier"), and to no-op gracefully when the precondition is absent. - Optional: auto-cancel
/loopschedules whose owning session has been compacted past the point where their setup was visible.
Repro
- In session A, schedule a
/loopwith a prompt that references session-A-only state. - Let session A compact past the setup.
- Wait for the wake-up to fire in the now-stateless session.
- Observe: agent has no way to validate the reference and tends to fabricate context.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗