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

Claude Code v2.1.307 ·

Remote session event uploads gain many server-set hold and flush settings

The server-sent policy that decides when a remote session's events and delivery receipts are held or sent gains many new settings and hold rules

Group of 7 Under the hood Internal Changes
JSON All of v2.1.307
Under the hoodTier: how much it should matter to you
2Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
SessionsArea: what it touches
Internal ChangesKind: in v2.1.307,
Internal ChangesSection of the release

What

When Claude Code runs as a remote session (labelled CCR), it uploads a stream of events, such as messages and acknowledgements, to a server. A flush policy sent by the server decides when those events are held back and when they are sent. Before, the policy only read max_events, max_age_ms, max_bytes, the flush_on_* settings, hold_across_model_calls, flush_before_tools_wait_ms, flush_after_tools, must_flush_types, live_twin_types, merge_worker_reports and policy_version. It now also reads:

  • joint_upload (jointUpload): a new offerToEventsPost step lets held rows travel along with the events POST, the upload request for events, when jointUpload is true and the rule is served_policy.
  • hold_again (holdAgain): endWholeTurnHold now takes the call that ended a whole-turn hold, and the hold is re-armed only if holdAgain includes that call; otherwise holdsNoMoreThisTurn is set. A new openTurn resets the hold state at the start of each turn. Before, a whole-turn hold simply became a hold for each call.
  • flush_after_tool_names (flushAfterToolNames); cleared tool-call tracking is reset when flushAfterTools changes.
  • may_wait_types (mayWaitTypes), transcript_max_age_ms (transcriptMaxAgeMs), control_traffic_keeps_hold (controlTrafficKeepsHold), empty_checkpoint_keeps_hold, the metadata_* settings such as metadata_max_wait_ms, and cost_report_max_wait_ms.
  • settings_receipts_max_wait_ms (settingsReceiptsMaxWaitMs) and messages_received_waits (messagesReceivedWaits).

Each setting is read from the policy and must be exactly true or a list. Nothing in the code gives a default that turns any of them on.

Receipts and answers can now be held too:

  • 'received' delivery receipts, which tell the server an event arrived, used to be sent straight away. They are now kept waiting for up to settingsReceiptsMaxWaitMs when the event is a settings request, or when messagesReceivedWaits is set and a hold is on, and are then sent together with 'processing' acknowledgements.
  • Answers to settings requests, which writeEvents used to send immediately, are held for up to settingsAnswersMaxWaitMs and sent together. A new sendWaitingAnswers step runs before a pickup acknowledgement.
  • Control-traffic events can leave a hold in place when controlTrafficKeepsHold is set, and incoming events now carry controlTraffic and settingsRequest flags.
  • On shutdown, beginShutdown() now calls sendWaitingReceipts() first.
  • Live-twin handling now also covers tool_progress heartbeats, the regular progress signals from running tools.

Why

How remote session events are batched and in what order acknowledgements go out can now be tuned from the server, but only for sessions whose server policy sets these values. Receipts that are still waiting when a session closes are now sent before shutdown instead of being left behind.

See this entry in the whole of v2.1.307 →

Feedback