Remote Control: archiving from the app disconnects the bridge (code 4090) but leaves the local bg session, registry entry and job record alive; app then shows it still open

Summary

Archiving a Remote Control session from the claude.ai web/phone app tears down the bridge before the local session is stopped. The local background session, its ~/.claude/sessions/<pid>.json registry entry and its ~/.claude/jobs/<id>/state.json record all outlive the archive, so local tooling that reads the registry still lists the session as live, and after a later /remote-control reconnect the claude.ai side treats the archived session as still open. Doing it in the other order (stop, then archive) is what the user expected the app to do.

Environment

• Claude Code 2.1.273 (CLI), Linux (Pop!_OS, kernel 7.1.5)
• Session started as a background job (kind: "bg", entrypoint: "cli"), then resumed from the phone app via Remote Control (SessionStart:resume hook fired, bridge_status "/remote-control is active")

Steps to reproduce

1. Start a session in the terminal, name it, hand it to Remote Control (/remote-control).
2. From the claude.ai phone app, open the session (it resumes locally as a bg session).
3. In the app, archive the session, then close it.

Observed (from the transcript JSONL, times UTC)

13:28:01  attachment  SessionStart:resume hook fires (session resumed by the app)
13:28:03  system      bridge_status: "/remote-control is active · Continue here, on your phone, or at https://claude.ai/code/session_..."
13:55:14  system      level=warning: "Remote Control disconnected — this session was ended or archived from another device or app (code 4090)"
          bridge-session record still written afterwards (bridgeSessionId cse_..., lastSequenceNum 2994)
14:00:58  system      local_command /remote-control (user reconnecting to find out why the app still showed it open)

After the 13:55:14 disconnect and until the user stopped it by hand around 14:01:

• a claude bg-spare process claimed for that session id was still running (idle, ~33 min elapsed)
• ~/.claude/sessions/<pid>.json still existed: "kind":"bg","status":"idle","bridgeSessionId":null,"name":"<session title>","jobId":"<job>"
• ~/.claude/jobs/<job>/state.json still read "state":"blocked" with the pre-archive detail/needs text
• the claude.ai session list showed the archived session as still open

Expected

Archive from the app should stop the local session first (or the disconnect with code 4090 should end the local bg process, remove the registry entry, and mark the job record done), and the app should show the session as closed/archived once. Archiving then closing should not leave a half-torn-down session that reads "open" remotely and "idle/live" locally.

Workaround

Stop the session locally first, then archive it in the app. Cleaning up by hand: kill the idle bg-spare process, remove the stale ~/.claude/sessions/<pid>.json, set the job state to done.