Summary

Emit a visible in-band notice when the claude-cli backend resets its CLI session and replays the transcript, so the continuation isn't mistaken for a rogue/duplicate agent.

Problem to solve

When a config reload / gateway restart changes the system prompt mid-conversation, the claude-cli backend invalidates its resumable CLI session, mints a new CLI session id, and replays the full transcript into the fresh session with the boilerplate "Continue this conversation using the OpenClaw transcript below as prior session history. Treat it as authoritative context for this fresh CLI session."

This reset is completely silent to the active conversation — it's only visible in host-side [agent/cli-backend] logs. From inside the running agent (and to anyone watching the transcript directory), the replayed session is indistinguishable from a second, concurrent agent instance that holds the entire transcript and is taking real actions — editing live config, spawning sub-agents — with no user involvement. Current behavior is insufficient because it gives the agent no signal that "the other session is just me, resumed." An agent that cannot read host logs has no way to self-diagnose this and will, correctly on the available evidence, escalate it as possible tampering. The result is a manufactured security scare for an entirely benign, single-process event.

Proposed solution

When a CLI session reset occurs, emit a lightweight event to the active session (and ideally to the channel surface), including the reason and the old/new CLI session ids. For example, a one-line system notice:

⟳ Session continued after a reset (reason: system-prompt). New CLI session 4b2a0475; prior transcript replayed as context.

Specifics:

• Make the reset observable in-band, not only in host-side [agent/cli-backend] logs.
• Include structured fields: reason, oldSessionId, newSessionId, historyReplayed: true.
• Ideally also expose it as a queryable runtime event (so a watchdog can correlate a config write with a known reset rather than flag it).

Alternatives considered

• Do nothing / document it. Weaker: the behavior still reads as an intrusion in real time; documentation doesn't help an agent reasoning from live evidence mid-incident.
• Suppress the "Continue this conversation…" boilerplate. Weaker and risky: that boilerplate is load-bearing for context continuity; hiding it would harm the replay, not clarify it.
• Only log to host side (status quo). Weaker: invisible to in-container agents and channel users — exactly the gap that caused the false alarm.
• Coalesce/throttle prompt-invalidating resets so a burst of reloads triggers fewer replays. Useful as a complement (reduces frequency) but doesn't address legibility, so it's not a substitute for surfacing the event.

Impact

• Affected users/systems/channels: any deployment on the claude-cli runtime; all channel surfaces (observed on webchat); most acutely, agents instructed to monitor their own state for tampering, and security-conscious operators.
• Severity: annoying-to-alarming. It does not break the agent's function (the edit/continuation succeeds), but it produces a false security positive that consumes real investigation effort and erodes trust in state integrity.
• Frequency: deterministic whenever the system prompt changes mid-conversation — i.e. on routine model/fallback edits, config patches, and gateway restart. For an actively-managed instance this is common, not an edge case.
• Consequence: wasted investigation time (host-log forensics, cross-agent handoffs), user anxiety about a possible intruder writing live config, and a standing risk that real incidents get discounted as "probably just the reset thing."

Evidence/examples

Real incident, 2026-06-24, OpenClaw 2026.6.10 (aa69b12), containerized single runtime (PID 8, activeSessions=1 throughout):

Two config edits to agents.defaults.model.fallbacks + gateway restart (SIGUSR1) reloads at 19:38 and 19:41:54. At 19:43:41 the backend reset:

19:43:41 [agent/cli-backend] cli session reset: provider=claude-cli reason=system-prompt
19:43:41 [agent/cli-backend] cli exec: ... reuse=invalidated:system-prompt historyPrompt=present promptChars=14039
19:43:41 [agent/cli-backend] claude live session start: ... activeSessions=1

A new transcript .../claude/projects/<workspace>/4b2a0475-….jsonl appeared, first entry a queue-operation with the "Continue this conversation…" boilerplate. The replayed session then edited openclaw.json and spawned a sub-agent. The active webchat session had gone idle at 19:43:23 (message_completed) — so this was sequential, same process, not concurrent — but nothing surfaced that fact, and it was initially investigated as a possible rogue/uncoordinated writer before host logs confirmed it benign.

Additional information

• Related, lower priority: there appears to be no file lock / single-writer guarantee around openclaw.json writes. With the current single-long-lived-process architecture a real race is unlikely, but if two runtimes ever coexisted they could clobber each other's edits. An advisory flock (or atomic write + compare-and-swap) on config persistence would be belt-and-suspenders — happy to split into a separate issue if preferred.
• Constraint worth noting: in proxy-restricted deployments, host-side logs may be the only current evidence of a reset, which is precisely why in-band surfacing matters for agents that can't reach them.