Summary

The chat.send handler was hardcoding disableBlockStreaming: true, which overrode the agents.defaults.blockStreamingDefault config setting. This caused TUI to ignore the blockStreamingDefault config and always stream token-by-token, overwriting previous content.

Root Cause

In src/gateway/server-methods/chat.ts at line 901, the webchat dispatch was setting:

disableBlockStreaming: true,

This hardcoded value prevented users from using blockStreamingDefault: on to get complete response blocks in TUI, unlike Telegram which respects this config.

Fix

Remove the hardcoded disableBlockStreaming: true so that the agent configuration agents.defaults.blockStreamingDefault is respected for TUI/webchat just like other channels.

Now users can set blockStreamingDefault: on in their config to get complete response blocks instead of streaming token-by-token.

Fixes

• Fixes [Bug]: TUI: blockStreamingDefault has no effect — assistant responses overwrite/wipe during streaming #19643

Greptile Summary

This PR makes three distinct changes:

1. Removes hardcoded disableBlockStreaming: true from the TUI/webchat chat handler (chat.ts), allowing the blockStreamingDefault agent config to take effect for webchat — consistent with how other channels (e.g., Telegram) already behave.

2. Removes dynamic timestamp generation from system prompt params (system-prompt-params.ts), removing imports of formatUserTime/resolveUserTimeFormat and no longer returning userTime/userTimeFormat. This is done intentionally to avoid breaking Anthropic prompt caching. The SystemPromptRuntimeParams type still declares these as optional, and all callers gracefully handle undefined, so this is safe. Agents can use session_status to get the current time instead.

3. Changes the elevatedDefault fallback from "on" to "off" in get-reply-directives.ts. This is a behavioral change that means elevated mode will default to off when no explicit config is set.

• The elevatedDefault fallback change introduces an inconsistency: directive-handling.persist.ts:73 and status.ts:391 still fall back to "on", which may cause the status display to report a different elevated level than what is actually applied at runtime.

Confidence Score: 3/5

• The core disableBlockStreaming fix is straightforward and safe, but the elevatedDefault fallback change introduces inconsistency with other code paths.
• The main fix (removing disableBlockStreaming: true) and the prompt caching improvement (removing userTime) are clean and correct. However, changing the elevatedDefault fallback from "on" to "off" in only one of three locations that resolve this value creates a behavioral inconsistency where status reporting and change-detection logic disagree with the actual runtime behavior.
• Pay close attention to src/auto-reply/reply/get-reply-directives.ts — the elevatedDefault fallback change has inconsistencies with src/auto-reply/reply/directive-handling.persist.ts and src/auto-reply/status.ts.

_{Last reviewed commit: 32d64a4}

_{(5/5) You can turn off certain types of comments like style here!}