Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial
HomeReleasesv2.1.204entry #1

Claude Code v2.1.204 ·

Entry
JSON All of v2.1.204
EntryKind: in v2.1.204,
Bug FixesSection of the release
  • Stream-json verbose mode now flushes buffered output at startup. When running with --output-format stream-json and --verbose together, any messages queued before the session writer was ready are now delivered immediately on initialization. Previously these early messages could be lost.
  • Trigger condition: xAb (the headless runHeadless entry point) evaluates l.outputFormat === "stream-json" && Boolean(l.verbose) (line ~884408) and, when true, calls Fdf(y) where y is the SDK session writer object (edn for local runs, Cgr for --sdk-url runs) created by PAb().
  • Buffer mechanics: Before the forwarder is registered, system-typed messages emitted via the internal oH() function accumulate in a per-session in-memory map (fWn). Buffering only occurs in non-interactive mode (Cn() returns !Rt.isInteractive) or when the REPL bridge is active (hx() returns Rt.replBridgeActive). The buffer is capped at 1,000 entries (PGh = 1000); when full, the oldest non-task_started/non-task_notification message is evicted first; if all remaining entries are task events, the oldest one is evicted.
  • Message types buffered: Any type: "system" event dispatched to oH() before registration — including subtypes task_started, task_updated, task_notification, task_progress, hook_started, hook_progress, hook_response, notification, and post_turn_summary.
  • Flush implementation (Fdf, line ~884227): Creates a flush callback t that calls lse() to destructively drain the current session's buffer (via Array.splice(0)), stamps each message with a fresh crypto.randomUUID() and the current session_id, then writes them one-by-one to the SDK writer via e.write(r).catch(() => {}) (write errors are silently discarded).
  • Persistent forwarding: After the initial flush, a3e(t) registers t as the global notify callback (Iqc = t). Subsequent oH() calls invoke Iqc?.() immediately after pushing to the buffer, so all future system messages are forwarded without delay for the remainder of the process lifetime. The callback is not cleaned up after startup (unlike the interactive TUI path which calls () => a3e(null) on unmount).
  • Evidence: Fdf / registerStartupSdkEventForwarder at line ~884227; call site guard at line ~884408; buffer/notify logic in oH / lse / a3e at lines ~275762–275784; buffer cap PGh = 1000 at line ~275808.

See this entry in the whole of v2.1.204 →

Feedback