Bug: "Cannot read properties of undefined (reading 'kind')" when a plugin calls agent.followup() with a bare string

[skyloader2474]

Bug: "Cannot read properties of undefined (reading 'kind')" when a plugin calls agent.followup() with a bare string

Environment

• DeepSeek Harness core 0.1.5-rc.1 (packages @deepseek-ai/dsh, @deepseek-ai/dsh-agent, @deepseek-ai/dsh-agent-loop, @deepseek-ai/dsh-time-context all 0.1.5-rc.1)
• Reproduced twice on this install (2026-09-15 and 2026-09-21), ~30 occurrences in local error history

Symptom

A turn ends with a red error:

{"type":"turn/end","data":{"turn":2,"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'kind')","code":"UNKNOWN"}}}}

The crash happens in under 1 ms after turn/start — before any step/start.

Minimal event sequence (durable session log, exact)

tool/result            (tool failed, isError:true)
turn/end               (turn 1, aborted by user)
agent/inbox/spliced    {target:"next-turn", start:0, removedCount:1, inserted:[], outcome:"canceled"}
agent/inbox/spliced    {target:"next-turn", start:0, inserted:["<a bare string, not a message object>"]}
turn/start             (turn 2)
agent/inbox/spliced    {target:"next-turn", start:0, removedCount:1, inserted:[]}   // claim shape, no outcome
turn/end               (turn 2, error: reading 'kind')

Root cause (code-level, traced through the shipped packages)

1. A third-party plugin calls agent.followup() with a plain string (its followupMessage config is a string template).
2. dsh-agent-loop followup(input) -> send() -> inbox.splice(...[message]) puts the string into the inbox without validation, so the durable agent/inbox/spliced event carries inserted: ["<bare string>"], violating the SessionEventMap contract inserted: UserMessage[].
3. The next turn claims the string; preStep() passes it to dispatch.waterfall("agent/pre-step", { messages: [...] }).
4. The built-in dsh-time-context prepend listener calls deriveBrowserTimeZoneContext(requestMessages(...decision.messages)), and browserTimeZone(message) does:

const source = message.source;
const value = source.kind === "user" && ...

message being a string, message.source is undefined, so this throws exactly Cannot read properties of undefined (reading 'kind').

Suggested fixes (defense in depth)

1. dsh-agent-loop.send() (and/or the inbox mutate) should validate/normalize inbox input — reject or wrap anything that is not a UserMessage. The durable log should never contain a non-message inside inserted.
2. dsh-time-context browserTimeZone() should use message.source?.kind (or equivalent guard) so a malformed claimed message degrades instead of crashing the whole turn.

Neither fix was present in the commit 32c6866 ("fix(time-context): preserve empty pre-step decisions"), which is the closest known upstream change to this code path (it addresses empty decisions, not unguarded source reads).

Notes

• No credentials, paths, or private content are included; the event list above is the full relevant trace.
• I'm happy to provide the full session log or a repro script if that helps.

[argszero]

Thanks for the trace — the exact event sequence and the pointer at browserTimeZone made this quick to pin down. I traced the same path in the current tree and reproduced it end to end with a real AgentLoop, a real durable inbox and the real dsh-time-context reader. Four things worth adding, ordered by how much they change the fix.

1. The write path's only check is a duplicate-identity guard, and what it reads is message.id

Your chain is exact: followup(input) → send(input, 'next-turn', true) → this.inbox.splice(resolvedTarget, Infinity, 0, [message]) (core/agent-loop/src/agent.ts:128, :137), with no runtime check on message anywhere on the way. The single structural check at that boundary is inside Inbox.mutate (core/agent-loop/src/inbox.ts:219-224):

const ids = new Set<string>()
for (const message of target === 'next-turn'
  ? [...candidate, ...state['next-step']]
  : [...state['next-turn'], ...candidate]) {
  if (ids.has(message.id)) throw new Error(`message "${message.id}" is already pending`)
  ids.add(message.id)
}

For a string, message.id is undefined. A lone string is the first entry added to the set, so nothing collides and the write succeeds. The boundary is therefore narrower than "no validation" and stranger than "unvalidated" — three consequences are worth knowing before widening it:

• two id-less entries in one splice are rejected, with message "undefined" is already pending — so at most one bare scalar can be pending at a time (this is why your event list shows a single inserted element);
• null and undefined never reach a reader at all: message.id throws a TypeError first, naming neither the value nor the inbox;
• an object carrying a unique id but no role/content/source passes both checks, and several can pile up.

2. There are three read placements, and the one your report does not reach throws from a different module

placement	control (no plugin)	with a consumer-side guard
string in next-turn, then claimed	TypeError: reading 'kind'	turn proceeds
string in next-step before a claim	TypeError: reading 'kind'	turn proceeds
string injected into next-step while a turn is running	TypeError: reading 'kind'	turn proceeds

The third row is the one I would flag. agent.inject('a string') — the same unvalidated write — puts the value where the next step will look, and agent-instructions walks agent.inbox.nextStep (core/agent-instructions/src/index.ts:321 → :65) and reads message.source.kind. That is a projection read, not a claimed batch, so it is reached before any claim takes the value out. Fix #2 applied to time-context alone leaves a path producing the identical error message, reached from a module you would not have guessed next. Measured against 0.1.6-alpha.2:

control   next-step injected mid-turn   THREW TypeError: reading 'kind'
guarded   next-step injected mid-turn   OK    nextStep=["msg"]

3. The replay path shares the hole

inboxProjectionSchema (core/agent-loop/src/inbox.ts:21-24) is z.array(z.custom<UserMessage>()) — a cast, not a check:

'next-turn': z.array(z.custom<UserMessage>()).readonly(),

Probed against the zod@4.6.5 that dsh-agent-loop itself declares (^4.4.3): a bare string in the wire state parses successfully, while a validating control rejects the same input. So a session that recorded the string is re-accepted on resume — fixing the write boundary does not by itself clean a session that is already affected, and a hand-repaired log is not protected either.

4. On the framing of fix #2

message.source?.kind stops the crash, but there is no meaningful degradation for a claimed batch element that is not a message: the reader would silently skip an entry the user's plugin meant to deliver, turning a loud failure into a quiet one. There are also N such modules (two today — the next one depends on registration order), against one write boundary.

A consumer-side plugin

Until a shape check lands at the write boundary, I've published the consumer half, since the symptoms are exactly what it exists for:

@argszero/cordis-plugin-inbox-input-guard@0.2.0 — source

npm install @argszero/cordis-plugin-inbox-input-guard

It sanitizes the batch at the point the loop takes ownership of it (agent.inbox.claim, so no listener order can matter), sweeps both pending lists at its agent/pre-step entry (which is what closes row 3 above), and observes agent/inbox/spliced so the defect is named at the write — with the session and the log seq — instead of surfacing later as a crash in an unrelated module. A scalar is delivered verbatim as a user message whose source records the repair, so what your plugin meant to say still reaches the model; anything whose text it cannot read unambiguously is dropped rather than guessed at; report mode changes nothing at all and only records.

Evidence: control arms for all three placements above, run against real Cordis, a real AgentLoop, a real durable inbox and the real time-context / agent-instructions readers; 24 behaviour tests; 4 packaging invariants; 20/20 mutations of the built output red; and a probe that runs the same arms against the installed artifact.

Honest boundaries: it cannot rewrite committed history — as you noted, the durable agent/inbox/spliced record keeps whatever was spliced — and it cannot name the plugin that wrote the value, because the inbox records a value and a value carries no caller. The upstream fix is still the shape check; this only keeps a session usable until then.

[skyloader2474]

Thanks for the detailed trace and for shipping the consumer-side guard — much appreciated.

On our side we went the producer-side route and it is already live: followup() now passes a full message object (id / role / content[] / source.kind) instead of a bare string, with 8 of 8 local assertions passing. Agreed that the shape check at the write boundary is the real fix — we will keep following this discussion for it.

[argszero]

Thanks for closing the loop — good to know the producer side is covered on your install.

For anyone still following this thread: the write boundary is unchanged at HEAD c36a83ff6b (dsh-v0.1.7-alpha.1). AgentLoop.send (packages/core/agent-loop/src/agent.ts:153-160) still hands the value straight to this.inbox.splice(...) with no runtime check on it, and the only structural read along the way is still message.id — in Inbox.mutate (packages/core/agent-loop/src/inbox.ts:219-224) and again in the rebuild path (:43-49). A bare string therefore still splices in cleanly, while null/undefined still throw a TypeError that names neither the value nor the inbox.

So a producer-side shape is the only protection today, and it is per-producer by construction: every caller that reaches followup/steer/inject has to guard itself, exactly as you did. Nothing further is needed from you.

The code path is byte-for-byte the one I measured, so the three read placements and the guard experiment above should still reproduce as written — I have not re-run that experiment on 0.1.7-alpha.1, only re-read the boundary. If it ever grows a shape check, the note will land here.