{"version":"2.1.307","anchor":"upload-hold-flush-policy-telemetry-and-knobs-expanded","canonical_anchor":"upload-hold-flush-policy-telemetry-and-knobs-expanded","heading":"Remote session event uploads gain many server-set hold and flush settings","tier":"internal","area":"Sessions","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.307\/e\/upload-hold-flush-policy-telemetry-and-knobs-expanded","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.307","markdown":"### Remote session event uploads gain many server-set hold and flush settings\n\nThe 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\n\n**What**\n\nWhen 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:\n\n- `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`.\n\n- `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.\n\n- `flush_after_tool_names` (`flushAfterToolNames`); cleared tool-call tracking is reset when `flushAfterTools` changes.\n\n- `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`.\n\n- `settings_receipts_max_wait_ms` (`settingsReceiptsMaxWaitMs`) and `messages_received_waits` (`messagesReceivedWaits`).\n\nEach 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.\n\nReceipts and answers can now be held too:\n\n- '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.\n\n- 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.\n\n- Control-traffic events can leave a hold in place when `controlTrafficKeepsHold` is set, and incoming events now carry `controlTraffic` and `settingsRequest` flags.\n\n- On shutdown, `beginShutdown()` now calls `sendWaitingReceipts()` first.\n\n- Live-twin handling now also covers `tool_progress` heartbeats, the regular progress signals from running tools.\n\n**Why**\n\nHow 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.\n\n- Area: Sessions\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5\n- Scope: individual\n- Heads-up: no"}