Reopening a project re-fires a stored kickoff prompt into a duplicate session instead of resuming the existing one

[RyanSeanPhillips]

Summary

On reopening a project after the laptop was closed, cldctrl appears to have re-fired a stored "kickoff" prompt into a brand-new session instead of simply restoring/resuming the session that already existed. The result was a duplicate session executing a stale prompt (asking the agent to redo work that had already been completed), while the real conversation — with the full scrollback — sat idle in the background. The user had no way to scroll back in the new session (it genuinely had no prior history) and was understandably confused about why "a handoff" had happened.

This was diagnosed from inside an affected session using the cldctrl MCP tools (get_active_sessions, search_conversations, read_session), so the evidence below is what those tools reported.

Environment

• OS: Windows 11
• Client: Claude Code (via cldctrl), model Fable 5
• Project: netsims — C:\Users\rphil2\Dropbox\spk_shape\for sushmita\netsims
• Date of incident: 2026-07-04

What seems to have happened

There is a prepared "kickoff" prompt for this project that begins:

Let's build my conference talk (Cleveland Homeostasis and Breathing symposium — bursts & burstlets; ...

Timeline reconstructed from get_active_sessions + search_conversations:

Session	Role	lastActivity (2026-07-04)	Notes
8c88b09b-bf89-4b7a-aa9b-6318191b032d	Prior work / handoff origin	17:21	originSessionId of the project memory note written 2026-07-03.
40bc83da-6c31-4e41-b7c2-55d5bf91a21f	Real interactive session	17:09	Received the kickoff prompt; user interacted (asked for a template review agent, PowerPoint questions); a 19-agent slide-build workflow ran and assembled the deck. This is the conversation the user remembers.
82b39300-3134-4e28-97bd-98724ae61c5f	Duplicate	17:30	Received the identical kickoff prompt ~20 min later. No prior history / no scrollback. Started re-doing already-finished work.

search_conversations returned the same opening snippet for both 40bc83da (113 matches) and 82b39300 (63 matches) — i.e. the same canned prompt landed in two distinct sessions.

Expected vs. actual

• Expected: reopening the project restores/resumes the existing session in place; a stored kickoff prompt fires once, for the session it was intended to seed — not again on every reopen.
• Actual: a new session was spawned and the kickoff prompt was re-injected into it, producing a duplicate that acted on stale context while the original session was left idle.

Impact

• Duplicate sessions doing redundant/stale work (wasted tokens + compute; risk of concurrent edits to shared project files).
• User confusion: the new session has no scrollback, so it looks like context was "lost" or a spurious "handoff" occurred.
• Agent acts on an out-of-date prompt (the kickoff was authored from planning docs that predate the work already completed in the original session).

Secondary observation — prompt encoding (possibly a separate bug)

The re-injected prompt arrives mojibake'd: em-dashes appear as ΓÇö and arrows as →. That is the classic signature of UTF-8 bytes decoded as Windows-1252 somewhere in the pipe that delivers the stored prompt to the session. Worth fixing regardless, and it's also a useful fingerprint that a prompt was injected programmatically rather than typed live.

Possible causes to investigate

• Resume-vs-launch logic: is a "resume" path accidentally creating a new session + replaying the kickoff prompt instead of reattaching to the existing one?
• Is the kickoff prompt persisted and replayed on every (re)start rather than being consumed once?
• Trigger on laptop sleep/wake, dashboard reconnect, or Dropbox re-sync of session state.
• Encoding of the stored prompt (UTF-8 → CP1252) in the delivery path.

Repro (best-effort)

1. Start a project session seeded with a stored kickoff prompt.
2. Interact so the session accumulates history; leave it at a stopping point.
3. Close the laptop (sleep), then reopen and return to the project.
4. Observe: a new session appears and the kickoff prompt is re-executed, while the original idle session retains the real history.

Possible enhancement — an MCP tool to file these automatically

It would be useful to have a cldctrl MCP tool that lets a running session file a bug/feedback issue against this repo directly (e.g. report_issue / file_bug). A session that detects an anomaly like a duplicate kickoff already has the exact evidence in hand — session IDs, timestamps, get_active_sessions/search_conversations output — and could attach it automatically with correct formatting, instead of relying on the user to notice and ask. It would also standardize including environment + session-graph context in every report. (This very issue was assembled by hand from those tools; a tool call would have produced it in one step.)