claude-code - 💡(How to fix) Fix Sessions auto-archiving within 30-90 min (only one project-dir bucket affected, started ~2026-05-09)

TITLE: Claude Code sessions auto-archiving within 20-90 min, dropping mobile bridge (started ~2026-05-09)

ENVIRONMENT

• claude-code 2.1.121–2.1.128 (Homebrew, installed 2026-04-27, unchanged otherwise)
• macOS Darwin 25.3.0 / Apple Silicon
• Model: claude-opus-4-7[1m], effort medium and xhigh (both reproduce)
• FleetView desktop app + Claude Code mobile app (bridge attached)
• MCP servers: obsidian only

SUMMARY

Active Claude Code sessions launched from the desktop FleetView app are auto-archiving within 20–90 minutes of activity, dropping the mobile-bridge connection and removing the session from the Active list. Heavy tool use accelerates the archive (one session today auto-archived in under 30 min while doing back-to-back git operations and security scans). The CLI process often keeps running for a turn or two but eventually breaks. The behavior started on or about 2026-05-09 with no local config or binary changes.

The workflow impact is severe: each archive event interrupts mobile remote-control access, the session has to be restarted from scratch, and ~2 hours/day of compounding context is lost.

REPRO

• Launch Claude Code from FleetView (account: [email protected] or [email protected])
• Begin development work (heavy tool use, file edits, multiple PR cycles)
• Within 20–90 min the session disappears from FleetView's Active list
• Mobile app loses access to the session

DIFFERENTIAL — IDENTICAL CONFIG, DIFFERENT BEHAVIOR

The same account has sessions in multiple project buckets. Only one is affected:

• /Users/jason/.openclaw/ bucket — 81 → 34 transcripts after cleanup; all archive
• /Users/jason/.openclaw/workspace/ bucket — 54 transcripts; no archive problem
• APEX / FOV / Alpha buckets — 1–3 transcripts each; no archive problem

Hypothesis: per-account policy keyed off cwd or transcript density, with this bucket tripping the policy.

SERVER FLAGS (from ~/.claude.json cachedGrowthBookFeatures)

These flag values are what differ for this account vs. fresh installs:

tengu_bridge_repl_v2_config.teardown_archive_timeout_ms = 1500   ← very aggressive grace
tengu_bridge_poll_interval_config.session_keepalive_interval_ms = 0    ← keepalive DISABLED
tengu_bridge_poll_interval_config.session_keepalive_interval_v2_ms = 0 ← v2 also DISABLED
tengu_bridge_poll_interval_config.heartbeat_interval_ms = 0
tengu_bridge_poll_interval_config.non_exclusive_heartbeat_interval_ms = 180000
tengu_bridge_repl_v2_config.heartbeat_interval_ms = 20000
tengu_bridge_repl_v2_config.http_timeout_ms = 10000

The combination of session_keepalive_interval_ms = 0 (keepalive off) + teardown_archive_timeout_ms = 1500 (1.5s grace) is the most likely culprit. The mobile bridge can't survive the slightest network blip with no recovery path.

SAMPLE BUCKET CHURN (today)

~/.claude/projects/-Users-jason--openclaw/
  2026-05-12 10:42  3b99485c... 660 KB    ← current
  2026-05-12 10:41  7baa49b8... 3.9 MB    ← archived mid-work (~25 min)
  2026-05-12 10:31  746e5acc... 3.9 MB    ← archived mid-work
  2026-05-12 10:01  bfaa73c8... 10.4 MB   ← archived mid-work
  2026-05-12 03:06  25974545... 1.7 MB    ← archived mid-work

5 sessions in 7 hours of one workday, average ~80 min before archive on lighter sessions, under 30 min on heavy-tool-use sessions.

WHEN IT STARTED

On or about 2026-05-09. No claude-code binary update has occurred since 2026-04-27. No local ~/.claude/settings.json or workspace settings.local.json changes in 14+ days. The behavior change correlates ONLY with GrowthBook feature flag refreshes (written to ~/.claude.json on every launch).

ASKS

1. Which flag or policy rolled out around 2026-05-09 for this account that disabled keepalive and reduced teardown grace?
2. Can keepalive be re-enabled and the teardown grace raised for this account?
3. Is there a user-facing opt-out planned, or a ~/.claude/settings.json knob to override the server flag values?

ATTACHED IF HELPFUL

• ~/.claude.json (cachedGrowthBookFeatures section, full)
• ls -lt of ~/.claude/projects/-Users-jason--openclaw/ showing churn

UPDATE 2026-05-12 (evening — bucket-theory invalidated)

Tested the workaround: launched a fresh Atlas 1b session from /Users/jason/.openclaw/workspace/ (the "clean" bucket — 54 transcripts vs the suspect bucket's 137). It auto-archived within ~30 minutes of opening.

So the bucket-density theory is wrong. The archive policy is NOT keyed off project-dir transcript count. It hits any session on this account regardless of cwd / project bucket.

Revised understanding: the trigger is per-account, not per-bucket. The disabled keepalive (session_keepalive_interval_ms: 0) and 1.5s teardown grace apply to every session this user opens, in every project. Switching project folders does not help.

Affected accounts on this user's machine: [email protected] and [email protected] confirmed. Likely [email protected] and [email protected] too but not directly tested.

ASKS (revised):

• Please confirm whether the keepalive flag rollout was per-user or per-account. If per-user, all 4 accounts on this machine are affected and the workaround has to be server-side.
• Any ETA on re-enabling keepalive for affected accounts?