[Bug?] Phantom user messages reach model context with future timestamps (never persisted)

[whoisKIKO]

What happens

Twice in one session, user messages appeared in the model's input that the user
never typed: duplicated up to ~12 times, some of them empty, with timestamps
~21 minutes ahead of wall clock. None of them was written to disk.

• 2026-10-29 00:16-00:17 (+11:00): ~12 copies of one short message plus several
  empty payloads.
• 2026-10-30 23:15:18 / 23:15:26 / 23:15:33 (+11:00): 3 further messages, same
  shape, different content.

Content is redacted (personal); both batches were ordinary short user messages
in Chinese.

Environment

dsh 0.2.1-rc.2, desktop app on Windows, desktop profile, web GUI on 127.0.0.1
(loopback), model deepseek-flash.

What I already ruled out

• Session log: no event carries those timestamps; no future-dated event exists.
• Projection cache, GUI localStorage / leveldb: the phrases are absent.
• Full-store search: the text appears only inside assistant replies.
• Server side: exactly 3 legitimate user submits per window, each rpcId once;
  no error / retry / timeout / abort.
• Host clock: accurate within 1-3s against three external sources; NTP running.

Code-level notes (review of the packaged dsh/ tree)

1. The inbox cannot deliver without committing. mutate() appends
   agent/inbox/spliced (dsh-agent-loop L204) and claim() (L103-110) goes
   through it; the frequent {"removedCount":1,"inserted":[]} splices are just
   claim traces.
2. Model input != inbox. preStep() (L902-927) runs the agent/pre-step
   waterfall (L909), where plugins may rewrite decision.messages - the only
   path by which content reaches the model without a session event. This profile
   has no third-party plugin installed.
3. Client time never reaches the model. beginSubmission() stores
   Date.now() only in pendingSubmissions (local echo; snapshot L816);
   prompt() (L186-192) sends {requestId, sessionId, mode, content, clientTimeZone} with no time field. Message time is written server-side.
4. So the earlier "uncommitted delivery" hypothesis does not hold.

Remaining possibilities

(a) the text reached the model through a non-inbox path, or (b) a local-echo
rendering was misread as a committed submission. These cannot be distinguished
from outside.

What I would like to know

1. Is there any path where agent/pre-step injection could duplicate user text?
2. Can a local-echo bubble (client clock) ever end up inside a turn's input?
3. Is there a supported way to log inbox / pre-step assembly without persisting
   content?

Session id and untruncated evidence can be provided privately.

[lubenkov]

There is an important distinction between rewriting the pre-step batch and sending unlogged text to the model.

In the architecture documentation for your reported dsh-v0.2.1-rc.2, agent/pre-step listeners can rewrite or reject the claimed messages. But for an admitted step, the documented flow appends the entered messages as user/message events and then derives model history from the log. The same document states the intended invariant: model-visible means logged.

So a pre-step listener could alter or duplicate the admitted batch, including a built-in listener; no third-party plugins are required in principle. But that alone does not explain text appearing in an actual model request with no corresponding reconstructable session state. That would need a separate explanation, such as a version-specific defect, a different request path, incomplete evidence, or a misunderstanding of what was observed.

Similarly, a local-echo bubble is not by itself evidence that its contents reached the provider. Also, text repeated by the assistant is not conclusive evidence of an additional user-role message in the request: the model could have generated it.

A useful next comparison would be, for one reproducible test with synthetic, non-sensitive marker text:

Capture the submitted request ID and the local-echo UI state.
Compare the admitted pre-step batch with the session events for that turn/step.
Compare those with the actual adapter-bound request, if you can instrument it locally.
Log only metadata by default: turn/step, message IDs, roles, source kinds, counts and lengths. Avoid raw content, credentials and public session IDs. If comparing content is necessary, use synthetic markers or a temporary keyed digest kept private.

I don’t know of a supported, content-free tracing switch for rc.2 so I wouldn’t assume one exists. If you can share the relevant event types and counts around one affected turn, that would help narrow down which boundary first diverges.

[whoisKIKO]

Thanks, that distinction helped — especially "an assistant repeating text is not
evidence of an extra user-role message". That one was fair.

One window, metadata only (24 events, 3 turns, no content):

• exactly 3 user/message events: 25 / 28 / 11 chars, one per turn, none duplicated;
• 3 assistant/message (866 / 142 / 176), 3 steps, turn ids consecutive (381-383), no gap;
• no long payload, no repeated text, no hidden turn.

So the duplication I reported does not exist in the session log at all. That leaves
your two remaining explanations: something in the assembled pre-step batch, or a
misreading on my side. I cannot distinguish them from outside, and I am not going to
instrument the adapter over a one-off.

Taking your advice: no packet capture, no logging switch, metadata only. I will reopen
only if it happens a third time.

Thanks again for the time.

Here's the event-type/count table for the affected window (metadata only, no content):

SESSION 90743347 WINDOW 2026-10-28 23:43 ~ 23:46 EVENTS 24

turn	step	event type	count	total chars	min-max
-	-	agent/inbox/spliced	1	25	25-25
381	-	agent/inbox/spliced	1	0	0-0
381	-	turn/start	1	0	0-0
381	1	agent/inbox/spliced	1	28	28-28
381	1	assistant/message	1	866	866-866
381	1	step/end	1	0	0-0
381	1	step/start	1	0	0-0
381	1	turn/end	1	0	0-0
381	1	user/message	1	25	25-25
382	-	agent/inbox/spliced	1	0	0-0
382	-	turn/start	1	0	0-0
382	1	agent/inbox/spliced	1	11	11-11
382	1	assistant/message	1	142	142-142
382	1	step/end	1	0	0-0
382	1	step/start	1	0	0-0
382	1	turn/end	1	0	0-0
382	1	user/message	1	28	28-28
383	-	agent/inbox/spliced	1	0	0-0
383	-	turn/start	1	0	0-0
383	1	assistant/message	1	176	176-176
383	1	step/end	1	0	0-0
383	1	step/start	1	0	0-0
383	1	turn/end	1	0	0-0
383	1	user/message	1	11	11-11

[lubenkov]

Agreed - closed from my side. The counts also map 1:1 (the splice lands one step before its user/message), so what you saw was queued-during-turn input, not duplication. Together with the offset, which points at client-side time, that exhausts the log explanation. Reopening on a third case with a synthetic marker is right

[argszero]

A content-free audit of each step's assembly now exists — and the third question has an answer on it.

@argszero/cordis-plugin-inbox-input-guard v0.3.1 (a git tag; the npm package stops at 0.2.0):

dsh plugin add "github:argszero/cordis-plugin-inbox-input-guard#v0.3.1"

It hooks agent.inbox.claim and agent/pre-step, and for every step records, in memory only: how many messages the inbox delivered (claimed), how many the waterfall let through (admitted), how many were added (added) and at which positions (addedAt), the source.kind of every addition, how many additions were empty, and the outcome. No message text, no tool arguments, no file paths — positions and kinds only.

The field aimed at this report is addedAsUser: an added message whose source.kind is user. The loop's own runtime context declares runtime-context and time-context declares time-context, so an addition carrying its own kind is the system talking; an addition claiming user is text impersonating the human. That is decidable with zero content, and a step where that count is non-zero is the phantom you described, named by position and kind.

On the third question — is there a supported way to log inbox/pre-step assembly without persisting content? I could not find one on 0.2.1-rc.2 or on rc.5; there is no switch for it, which matches what @lubenkov found. This ledger is the alternative that exists today.

One boundary, because it decides how far the fix goes: packages/core/agent-loop/src/agent.ts appends its own context at the fallback (return [...claimed, context]), so a plugin around the waterfall observes the batch and cannot make phantom text impossible. A listener names the step, the position and the kind; it cannot keep the text out. Prevention belongs to a shape check on the inbox write path, and to inboxProjectionSchema, whose z.custom<UserMessage>() accepts any value on replay.