{"version":"2.1.309","anchor":"ccr-worker-upload-flush-policy-gains-new-fields-delivery-re","canonical_anchor":"ccr-worker-upload-flush-policy-gains-new-fields-delivery-re","heading":"Remote session event batching gains new server-controlled settings","tier":"internal","area":"Cloud Sessions","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309\/e\/ccr-worker-upload-flush-policy-gains-new-fields-delivery-re","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309","markdown":"### Remote session event batching gains new server-controlled settings\n\nThe rules that decide how remote Claude Code sessions batch and send their events gain several new server-supplied settings, including receipts riding uploads\n\n**What**\n\nWhen Claude Code runs as a remote worker (Claude Code Remote, where a session is driven from elsewhere), it sends the session's events to a server in batches. The rules for when a batch is sent, called the flush policy, come from the server's remote configuration. That policy gains new settings, each spelled two ways (one in Claude Code, one in the remote config):\n\n- `receiptsRideUploads` \/ `receipts_ride_uploads`: when on, 'processed' delivery receipts wait and go out with the next upload instead of being sent on their own.\n\n- `liveOnlyTypes` \/ `live_only_types`: rows of the listed types are treated as ephemeral, meaning they are sent live but not kept.\n\n- `noTurnMaxAgeMs` \/ `no_turn_max_age_ms`: a maximum age for held events while no turn (one round of you asking and Claude answering) is open.\n\n- `initMaxWaitMs` \/ `init_max_wait_ms`: when the hold switch is on, `writeEvents` holds startup (init) events and replayed user messages for this long, alongside settings answers, which are held for `settingsAnswersMaxWaitMs`.\n\n- `firstIdleWaitsForWork` \/ `first_idle_waits_for_work` and `firstTurnHoldsEachCall` \/ `first_turn_holds_each_call`: further wait rules for the first idle period and the first turn.\n\nBefore this release, the only events held back were batches made up entirely of settings answers. All the new settings are optional and fall back safely when the server does not send them. They are included in the check that decides whether the policy has changed and are reported in telemetry. Alongside them, `waitsForStatus` now holds status reports back until `startReportsWaitUntilMs` when `mergeWorkerReports` is set, metadata sends that fail are now put back in the queue separately, and `transcriptRowMayWait` takes a third argument.\n\n**Why**\n\nThese settings change how often and how quickly a remote session's events reach the server, and the server, not you, decides their values. In practice some events may be held a little longer and sent together, and delivery receipts can stop needing their own separate post.\n\n- Area: Cloud Sessions\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5\n- Scope: individual\n- Heads-up: no"}