WSL bridged sessions stop after ~15 min idle and are not relaunched — session_keepalive_interval_ms is 0 while the client default is 120000

Title: WSL bridged sessions stop after ~15 min idle and are not relaunched — session_keepalive_interval_ms is 0 while the client default is 120000

What happens

Running Claude Code in WSL2 from the Windows desktop app (five pinned sessions, one project), an idle session's CLI process exits and is not relaunched. The session then cannot be reached — cross-session messaging to it fails with ECONNREFUSED on a stale socket, and it is absent from ListAgents. The only recovery is typing into that chat in the app, which spawns a new process and reattaches the session.

Active sessions are fine. This only affects sessions that go quiet.

What I measured

A 1-minute cron sampled the session processes for 29 hours (1,742 samples, 2026-08-12T20:12Z → 2026-08-14T01:17Z), recording each pid's lifetime at death.

63 deaths. Two clearly distinct modes:

1. A ~15-minute idle timeout — 15 of 63 deaths (23%) inside a 2.5-minute-wide band:

14m03s · 14m08s · 14m12s · 14m14s · 14m27s · 14m27s · 14m31s · 14m32s
14m39s · 14m47s · 14m57s · 14m58s · 14m59s · 15m35s · 15m47s

7 of those died alone (no simultaneous deaths), so it is not a shared external event.

2. Mass simultaneous deaths — 8 at once (a host restart), 6, 4, and several pairs. Expected; not the subject of this report.

Sessions that were actively used lived 12h52m – 18h47m and died only at the host restart. So activity keeps a session attached; roughly fifteen minutes of silence ends its process.

The configuration that appears to explain it

From ~/.claude.json → cachedGrowthBookFeatures:

tengu_bridge_poll_interval_config.session_keepalive_interval_ms    = 0
tengu_bridge_poll_interval_config.session_keepalive_interval_v2_ms = 0
tengu_ccr_idle_heartbeat                                           = true
tengu_ccr_bridge_multi_session                                     = true

The client's own schema for that field defaults to 120000 ms:

session_keepalive_interval_v2_ms: int().min(0).default(120000)

So the keepalive feature is enabled (tengu_ccr_idle_heartbeat = true) while its interval is served as 0.

Why this is WSL-specific (checked, not assumed)

The flag values are identical on the Windows host and inside WSL — both 0. The difference is architectural:

• Windows-native: the desktop app runs sessions directly. ~/.claude/remote does not exist.
• WSL: sessions run through the bridge — ~/.claude/remote/srv/<hash>/server --serve --socket … proxying to ~/.claude/remote/ccd-cli/<version>.

The disabled setting is a bridge setting (ccr / bridge naming), so on Windows there was nothing for it to govern. The same account, same flags, produced no symptom for months on Windows and this symptom immediately in WSL.

Supporting detail: process recycling through the bridge is normal and transparent — one of my sessions ran under 14 different pids in a day with unbroken context, each relaunched as ccd-cli … --resume=<sessionId>. The recycling isn't the problem; the absence of a keepalive for idle sessions is.

Impact

A multi-session workflow (several pinned chats coordinating on one project) needs manual reactivation of every quiet session, repeatedly. Automation that messages another session fails silently from the sender's side: the send is accepted, the target is gone, nothing indicates it.

Questions

1. Is session_keepalive_interval_ms = 0 intended for WSL/bridged sessions, or is the client default of 120000 the intended value?
2. Is there a supported user-side override (setting or env var)? I found CLAUDE_CODE_IDLE_THRESHOLD_MINUTES (default 75, appears to be a different concept) and CLAUDE_CODE_FORCE_SESSION_PERSISTENCE (transcripts), neither of which governs this.
3. If a keepalive isn't intended, is there a supported way for an idle bridged session to be reachable without a human typing into its window?

Environment

• Claude Code 2.1.229, Windows desktop app → WSL2
• Ubuntu 26.04 LTS, kernel 6.6.87.2-microsoft-standard-WSL2
• 5–6 concurrent pinned sessions, one project directory
• Bridge: ~/.claude/remote/srv/<hash>/server --serve

What I am not claiming

I have not proven the flag causes the exits — I have a strong correlation (a disabled keepalive, a tight ~15-minute idle cluster, and a WSL-only architecture that introduces the component the flag governs) and no visibility into the bridge's own logic. If the mechanism is something else, the census data is available.