[BUG] Remote Control sessions batch auto-archived server-side days after disconnect; hidden from mobile with no unarchive or retention setting

Status Open
Reported on v2.1.275
Maintainer reply None cached
Activity 0 comments · opened Sep 25, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Remote Control sessions (origin: claude_code_cli, environment_kind: "bridge", tag remote-control-sdk) are transitioned to SESSION_STATUS_ARCHIVED by a server-side process without any user action — observed as a BATCH days after the sessions' last activity, not only the ~10-minute idle case in #32651 (closed as not planned). The Claude mobile app hides archived sessions and offers no way to view or unarchive them, so a session the user deliberately enabled Remote Control on silently vanishes from their phone.

Evidence from this account's session list (Claude Code Remote API, list_sessions):

| Session | Last real activity | Archived stamp (updated_at) |
|---|---|---|
| session_01Lit3T87NnjAbHwkPxYR4sj ("Memory overhaul implementation" — Remote Control explicitly enabled) | 20 Sep 2026 | 2026-09-21T10:29:41.97Z |
| session_01SaC5Ano3FqaRcrDqpF5w8S ("NOTIFY action for email rules") | 18 Sep 2026 | 2026-09-21T10:29:43.06Z |

  • Archival stamps are 1.1 seconds apart, days after each session's last activity → a scheduled/batch server-side reaper, not user action or client cleanup (/exit was not used).
  • Nearly every remote-control-sdk bridge session on the account ends up ARCHIVED, including some with connection_status: "connected"; anthropic_cloud sessions from the same period stay idle/unarchived.
  • Calling unarchive_session fully restores the session and it reappears in the mobile list — mobile simply filters archived sessions; the data is intact.

What Should Happen?

  1. The archival lifecycle for Remote Control sessions is documented (which component, what timeout).
  2. Recently-active sessions are exempt — e.g. never auto-archive a session active in the last 24 h, ideally as a user-configurable retention setting. (cleanupPeriodDays / desktopSessionCleanupPeriodDays only govern LOCAL transcript files and do not control this.)
  3. Mobile parity: the Claude mobile app can show archived sessions, or at least unarchive them, so a swept session is recoverable without API access.

Error Messages/Logs

Steps to Reproduce

  1. On macOS, run claude remote-control in a project directory; the session appears in the Claude mobile app (tag remote-control-sdk, environment_kind bridge).
  2. Work in it, then disconnect (quit the CLI / laptop sleeps). Do NOT run /exit and do not archive it.
  3. Wait 1+ days.
  4. The session flips to SESSION_STATUS_ARCHIVED with no user action — in our case two sessions were stamped 1.1 s apart (2026-09-21T10:29:41.97Z and 10:29:43.06Z), days after their last activity.
  5. Open the Claude mobile app: the session is gone from the list. Only unarchive_session via the Claude Code Remote API brings it back.

Claude Model

_No response_

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.275 on the affected sessions (account range 2.1.266–2.1.280)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Cursor

Additional Information

Related: #32651 reports the same symptom class at ~10 min idle and was closed as not planned — this report adds exact timestamps and a multi-day batch-archival data point, plus confirmation that unarchiving restores mobile visibility.

Impact: enabling Remote Control expresses "I want to reach this session from my phone"; the sweep silently defeats exactly that, with no recovery path in the mobile app.

---
_Generated by Claude Code_

View original on GitHub ↗