{"version":"2.1.314","anchor":"sse-transport-gains-a-long-poll-fallback-gate-default-on-f","canonical_anchor":"sse-transport-gains-a-long-poll-fallback-gate-default-on-f","heading":"Remote session connections can fall back to long polling when a proxy buffers the stream","tier":"notice","area":"Sessions","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.314\/e\/sse-transport-gains-a-long-poll-fallback-gate-default-on-f","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.314","markdown":"### Remote session connections can fall back to long polling when a proxy buffers the stream\n\nThe remote session streaming connection gains a long-poll fallback for silent connections, controlled by CLAUDE_CODE_CCR_LONG_POLL or a gate\n\n**Unclear.** Nothing shows what makes a connection ask for a long poll, so this path may never run.\n\n**What**\n\nRemote sessions receive updates over a streaming connection (SSE, a single long-lived connection the server keeps sending data down). Some proxies hold back that data, so the connection looks silent. The CCR SSE connection used by remote sessions now has a fallback to long polling, where the client asks the server for a response, the server answers and closes, and the client immediately asks again.\n\n- The connection counts, per connection, how many body bytes arrived and how many connections in a row closed without delivering anything (`bodyBytesThisConnection`, `silentConnectionStreak`).\n\n- After a run of silent connections it switches into long-poll mode (`longPollMode`) and asks the server for long-poll responses on later connects (`askedLongPollThisConnection`). The message it records says it is \"asking the server for long-poll responses (a proxy may be buffering the response body)\".\n\n- When a long-poll connection finishes cleanly and either moved the conversation forward or ran past a time limit, it logs `SSETransport: Long poll completed, reopening` and reopens at once instead of going through the normal reconnect path. Before, a stream ending always logged `SSETransport: Stream ended, reconnecting`.\n\n- Redials in long-poll mode are quiet (`quietRedial`) and skip the usual connection reporting.\n\n- The timeout that decides a connection is dead now allows for the long-poll interval the server reports back. Before, it was `keepaliveIntervalMs()` plus a fixed margin.\n\n- The environment variable `CLAUDE_CODE_CCR_LONG_POLL` overrides the behaviour: `true` forces long polling, `false` turns it off.\n\n- Without that variable, the new `longPollFallback` option decides. It is set only when the client owns the process, a further check passes, and the gate `tengu_ccr_sse_long_poll_fallback` allows it. Nothing has been read about that gate's value.\n\n**Why**\n\nIf your network sits behind a proxy that buffers streamed responses, a remote session could appear to hang or keep reconnecting. This fallback gives such connections another way to get updates, and `CLAUDE_CODE_CCR_LONG_POLL` lets you force it on or off yourself.\n\n- Flag `tengu_ccr_sse_long_poll_fallback`: Not enough to say (read for one account on one subscription tier against v2.1.314; this account: no value returned, anonymous baseline: no value returned, compiled default: on) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Flag `tengu_ccr_sse_keepalive_max_interval_s`: Not enough to say (read for one account on one subscription tier against v2.1.314; this account: no value returned, anonymous baseline: no value returned, compiled default: not a boolean we can read) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: Sessions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5\n- Scope: individual\n- Heads-up: no"}