Incoming peer messages now pass rate, duplicate and loop checks before queuing, with drops shown to you.
tengu_harbor_kite_limits Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.223: 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.
Read once, for one account on one subscription tier, against v2.1.223. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
Incoming peer messages are checked before they reach the queue, so a runaway relay chain or a flood from one sender is dropped rather than processed.
- checks are a per-sender token bucket, a duplicate-body window, a self-hop loop detector, a relay-chain length cap, and a cap on queued peer messages
- built-in defaults: bucketCapacity 30, refillPerSecond 0.5, dedupWindowMs 30000, maxSelfHops 10, maxChainLength 28, maxTrackedSenders 256
- limits are read from remote config key
tengu_harbor_kite_limitsand fall back to that built-in defaults object - rejections surface to the user as a drop notice and are counted in telemetry
message has already passed through this session (a peer messaging loop)
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.232
Hidden cross-session inbox row in the settings dialog
Both mention harbor kite
-
v2.1.248
Kite network transport now defaults on, including on Windows
Both mention harbor kite
-
v2.1.224
New ListAgents tool for finding other sessions you can message
Both mention harbor kite