Remote sessions now rebuild a stuck connection when heartbeats keep failing but data still flows.
tengu_bridge_selfheal_heartbeats Off by default, switched on for this accountThe shipped code defaults this off, and the flag server returned on for the one account this site reads on this version. That is the reading that makes the entry above worth a second look, and it still says nothing about your account.
This account: on · anonymous baseline: on · compiled default in v2.1.222: off
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.
Read once, for one account on one subscription tier, against v2.1.222. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
The v2 remote-control transport now counts consecutive presence heartbeat failures and, when heartbeats keep failing while the SSE read stream still looks alive, closes with a new code 4093 and rebuilds the transport rather than sitting on a dead connection.
- New close code 4093 with human-readable reason text explaining that presence heartbeats to the server kept failing.
- New internals: resetHeartbeatStreak, onHeartbeatLost, and isReadStreamRecentlyAlive, which is what distinguishes a stalled heartbeat from a genuinely dead read stream.
- Gated on tengu_bridge_selfheal_heartbeats; the fallback value in source is true, with the real value coming from remote config.
- Skipped entirely when the session is outboundOnly.
presence heartbeats to the server kept failing (code 4093)
Strings lifted out of the shipped bundle, so the claim above can be checked against them.