›_ Claude Code Issues
Claude Code Issues / #71616

[BUG] All newly-created Code sessions auto-archive on iOS and become inaccessible from mobile app

Status Open
Reported on v2.1.119
Maintainer reply None cached
Activity 4 comments · opened Jun 26, 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?

Every Code session I create is being automatically moved to the "Archived" tab on the iOS Claude app within minutes of creation, and I can no longer interact with any of them from mobile.

This started about a month ago and has progressively worsened. At first it was intermittent — only some sessions auto-archived while others stayed accessible. As of today it affects every session: 100% of new sessions auto-archive on mobile and become completely inaccessible from the app.

Key observations:

  • Sessions show a green "Connected" status while sitting in the Archived tab, so the connection is alive — they're just locked behind the archived state with no unarchive option on mobile.
  • The only session that stays OUT of Archived is one I'm continuously interacting with. The moment a session goes briefly idle after creation, it gets auto-archived. This points to the auto-archive logic firing on active sessions that shouldn't qualify.
  • The problem is mobile-only. On my Mac, the CLI shows every session as healthy and unarchived — nothing is archived on that side. The mismatch is entirely between the iOS app and the actual session state.
  • The "All" tab on mobile only shows older, Disconnected sessions; all my live Connected sessions end up in Archived.

Net effect: the mobile app is currently unusable for Code. The Mac terminal where I initiate the session is my only way to access these sessions.

Possibly related: #32651, #59449, #32018

What Should Happen?

A connected, active session should remain in the active list and stay interactive from mobile. The Archived tab should only contain sessions the user explicitly archived or that are genuinely inactive on the server. Mobile archive state should match the actual server/CLI state, and there should be a way to unarchive a session from the mobile app.

Error Messages/Logs

Steps to Reproduce

  1. On Mac: start or confirm a Code session is active and connected.
  2. On iOS: open the Claude app and go to the Code section.
  3. Create a new session, or view an existing active one.
  4. Leave it briefly idle (~5 min).
  5. Session moves to the Archived tab while still showing "Connected."
  6. Tap it — shows "Archived" state, no unarchive option, no interaction possible.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.119

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

4 Comments

devinbalkind · 2 months ago

Seeing this same active-session auto-archive on macOS via the CLI / Remote Control, so it's not iOS-only — adding data points in case they help isolate the trigger:

  • Claude Code 2.1.195, macOS (Darwin 25.5.0), claude.ai subscription OAuth (not API key).
  • The affected session is long-lived and recently active (driven remotely), yet gets archived on its own and has to be manually unarchived — and it re-archives later. Matches your observation that the auto-archive logic is firing on sessions that shouldn't qualify.
  • On the Mac/CLI side the session shows healthy/unarchived even while it's archived on the remote/mobile side, consistent with the per-client mismatch others have noted.

Likely the same root cause as #67360 (Remote Control JWT-refresh 401 / concurrent-session token-refresh race) — the archive seems to coincide with a reconnect/token-refresh boundary rather than genuine idleness. Filed #71873 separately before finding this; closing that as a duplicate in favor of this issue.

js-1105 · 1 month ago

Same symptom here, with host-side log evidence. Setup: Mac Studio (always-on, Ethernet, pmset sleep 0), sessions created in the macOS desktop app with "Enable remote control by default" on; viewers: iPhone + MacBook, same account/org.

Every morning, ALL sessions from the previous evening show as archived on iOS ("No sessions found. All sessions are archived."). Host-side main.log shows the machine was healthy all night: device-bridge heartbeats at 23:50, 00:10, 01:01, 02:53, 06:00; OAuth token refreshes succeeding; no app restart. The sessions' local JSON still has isArchived: false and their bridgeSessionIds intact — the cloud archived state contradicts the host state.

Three additional data points:

  1. Tapping Unarchive on iOS produces zero events in the host log (checked the exact minutes) — it only flips the cloud label; the session stays read-only on mobile.
  2. Re-enabling via /remote-control on the host always recovers the session instantly — but the fresh bridge does not survive the night either (bridge enabled at 22:10, archived again by morning).
  3. This repeats every single night; it is not correlated with host sleep (host never sleeps) or network (Ethernet, no drops logged).

Happy to provide fuller logs if useful.

js-1105 · 1 month ago

Follow-up with two more data points from systematic elimination testing:

  1. Bridge instability pattern (host main.log): the [remote-control] bridge reconnects all night with widening gaps — reconnects at 23:50, 00:10, 01:01, 02:53, 06:00 (gaps up to ~3h). Sessions appear to get archived during a long disconnect window, and reconnection never un-archives them (one-way ratchet). This would explain why daytime sessions rarely archive (short gaps + user activity) while every overnight session dies.
  1. iOS shows nothing even for healthy bridges, browser included: a fresh CLI session started with claude --remote-control (process alive, bridge_state: connected, handoff: publishing logged) is visible nowhere — not in the macOS desktop app viewer, not in iOS app, not in mobile Chrome on claude.ai/code. Meanwhile desktop-app sessions re-enabled via /remote-control DO appear on the MacBook viewer but still never on the phone (same account, same workspace — verified; single-workspace account). So the phone-side view seems broken independently of bridge health.

Environment: macOS desktop app + CLI v2.1.205, single claude.ai account (Max), Mac Studio always-on host.

js-1105 · 1 month ago

Additional evidence from another setup (macOS desktop app → iOS), observed 2026-07-28 → 2026-07-31

Environment: macOS (Darwin 25.5.0), Claude desktop app 1.24012.9 (installed Jul 24, unchanged since), embedded Claude Code component 2.1.219, and Settings → Claude Code → Local sessions → "Enable remote control by default" = ON.

What we found on the desktop side, which may explain the iOS "auto-archive / inaccessible" symptom:

  1. ~/Library/Logs/Claude/main.log shows regular Enabling remote control for session local_* entries up to 2026-07-28 20:00 local — then zero such entries for the next three days, despite daily use and several newly created sessions. The app binary did not change in that window, so we suspect a silent auto-update of the embedded Claude Code component switched to a new bridge architecture (logs now show [sessions-bridge] Registering environment, env_* / cse_* identifiers, [buddy] starting bridge).
  2. Sessions created after 2026-07-28 have no bridgeSessionIds field at all in ~/Library/Application Support/Claude/claude-code-sessions/<acct>/<org>/local_*.json. Sessions created earlier retain 1–2 stale bridge IDs that no longer resolve remotely.
  3. With the "Enable remote control by default" toggle ON, even the currently running, actively used session does not appear on any remote device.
  4. A full quit + relaunch of the desktop app did not restore auto-publication — it made things worse: the two sessions still visible on iOS disappeared after the relaunch. The new bridge components do start on boot ([sessions-bridge] Environment registered, [remote-tools-device] authenticated), but no per-session enablement ever follows.
  5. The only thing that still works: manually typing /remote-control inside a session. That session then appears on iOS within seconds — per-session, manual only.

In short: on our machine the mobile-side invisibility correlates with the desktop app silently ceasing to (re)publish session bridges after 2026-07-28, while the manual /remote-control path still registers a fresh bridge successfully. Hope the contrast between the dead automatic path and the working manual path helps narrow down the regression.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Browse all Claude Code issue topics →