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: jason@fuse.fit or subpej@gmail.com)
- 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
- Which flag or policy rolled out around 2026-05-09 for this account that disabled keepalive and reduced teardown grace?
- Can keepalive be re-enabled and the teardown grace raised for this account?
- Is there a user-facing opt-out planned, or a
~/.claude/settings.jsonknob 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: jason@fuse.fit and subpej@gmail.com confirmed. Likely jpejsa@gmail.com and ops@fuse.fit 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?
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗