Assistant reply is written to session jsonl but not displayed in Claudian UI

[Bluck2022]

Hi, thanks for building Claudian.

I ran into an issue where Claudian completes the request successfully, but the assistant reply text does not appear in the chat UI.

Environment

• OS: Windows
• Obsidian version: 1.12.4
• Installer version: 1.6.7
• Claudian version: 1.3.67

Problem

When I send a simple message such as "Hello" or "Are you there?", Claudian appears to finish normally, but the assistant text is missing from the UI.

I only see status lines like:

• Thought for 0s
• Finagled for 8s
• Cooked for 5s
• Steeped for 22s

The actual assistant reply body is not rendered.

Expected behavior

The assistant's text reply should appear in the chat panel after the request completes.

Actual behavior

The request finishes, but only the thinking or status text is displayed.
The assistant message content is missing in the Claudian UI.

What I already checked

• Claudian is installed correctly and enabled
• Claude CLI path is valid and points to:
  C:\Users\.local\bin\claude.exe
• I tested after restarting Obsidian
• I tested after starting a new chat
• I checked Obsidian Developer Console
• There is no obvious Claudian-specific frontend error
• The only visible console error is from another plugin (remotely-save), which seems unrelated
• I also tested with loadUserClaudeSettings disabled, but the issue remained

[Bluck2022]

The problem was not that the provider failed to return an answer.
The assistant reply was successfully received and persisted in the Claude session log, but Claudian failed to render the reply text in the chat UI.

In this case, the UI showed only status/thinking lines such as:

Thought for 0s
Finagled for 8s
Cooked for 5s
Steeped for 22s
while the actual assistant text body was missing.

I confirmed that the underlying session jsonl contained a normal assistant message with valid text content. For example, the final assistant payload had this shape:

{
"type": "assistant",
"message": {
"role": "assistant",
"model": "MiniMax/MiniMax-M2.5",
"content": [
{ "type": "text", "text": "..." },
{ "type": "thinking", "thinking": "..." }
]
}
}
So the response existed and was persisted correctly. The bug was in UI-side rendering / stream deduplication, not in request execution.

Root cause

The bug appears to be in Claudian’s logic that prevents duplicate rendering between:

streamed text events, and
the final assistant message
Claudian tracks whether it has already seen streamed text, and if so, it skips text from the final assistant message to avoid showing the same reply twice.

That general idea is reasonable, but the current implementation is too broad.

The relevant logic was effectively:

if (event.type === "content_block_start") {
return event.content_block?.type === "text";
}
if (event.type === "content_block_delta") {
return event.delta?.type === "text_delta";
}
and later:

if (message.type === "assistant" && sawStreamText && event.type === "text") {
continue;
}
This means Claudian marks “stream text was seen” purely based on the event type being text or text_delta, without checking whether that streamed block actually contains visible user-facing text.

That becomes a problem with some Anthropic-compatible providers, because they may emit:

empty text_delta events
placeholder text blocks
non-standard sequencing where the real visible answer only appears in the final assistant message
In that situation, Claudian incorrectly concludes:

“text was already rendered from the stream”
and then suppresses the real text block from the final assistant message.

The result is exactly what I observed:

thinking/status UI is shown
final assistant text exists in the log
but the actual reply body is dropped from the UI
Why this likely affects Anthropic-compatible providers

The plugin appears to assume a tighter relationship between streamed text blocks and final assistant text than some compatible providers actually guarantee.

With official Anthropic-style behavior, the current heuristic may often work well enough.

With compatible providers, you can get cases where:

stream events include text / text_delta markers
those streamed text blocks are empty or not the real visible answer
the real answer is only present in the final assistant message
Claudian suppresses that final text because sawStreamText was already set
So the issue is not that the provider response is invalid.
It is that the UI deduplication logic assumes that the existence of a streamed text event implies that visible assistant text has already been rendered.

That assumption is too strong.

The fix

I fixed it by narrowing the condition that marks a stream event as “real streamed text”.

Instead of treating any text / text_delta event as visible text, I changed the logic so it only returns true when the block actually contains non-empty, non-placeholder text.

The patched logic is:

if (event.type === "content_block_start") {
return event.content_block?.type === "text"
&& !!event.content_block.text
&& event.content_block.text.trim() !== ""
&& event.content_block.text.trim() !== "(no content)";
}
if (event.type === "content_block_delta") {
return event.delta?.type === "text_delta"
&& !!event.delta.text
&& event.delta.text.trim() !== ""
&& event.delta.text.trim() !== "(no content)";
}
This ensures that sawStreamText is only set when there is actual visible assistant text in the stream.

Why this fix works

After this change:

empty streamed text events no longer count as “text already rendered”
placeholder values like "(no content)" no longer trigger deduplication
if the real assistant text only appears in the final assistant message, Claudian will still render it
That resolved the issue immediately in my environment. After the patch, the assistant reply body appeared correctly in the UI.

Recommended upstream change

I would recommend that Claudian update its stream deduplication logic along these lines:

Only mark streamed text as seen when the stream block contains real visible text.
Do not suppress final assistant text solely because a text / text_delta event was observed.
Base deduplication on “rendered visible content” rather than just “text event type encountered”.
In other words, the guard should be semantic, not structural.

Even safer version

A more robust approach would be:

track whether any visible assistant text was actually rendered to the UI
only suppress final assistant text if visible text was already rendered
otherwise always allow the final assistant message to populate the chat bubble
That would make the renderer more tolerant of provider differences in streaming behavior.

Short maintainer-facing summary

The bug is caused by overly aggressive stream/final-message deduplication.

Claudian currently treats any streamed text / text_delta event as evidence that assistant text has already been rendered, then suppresses text blocks from the final assistant message.

Some Anthropic-compatible providers may emit empty or placeholder streamed text events while placing the actual answer only in the final assistant message.

Because of that, the final assistant text gets incorrectly dropped from the UI.

The fix is to mark sawStreamText only when the streamed block contains actual non-empty visible text, for example by checking that text.trim() is neither empty nor "(no content)".