[BUG] Remote Control: shutdown archives a constructed `session_` ID and books a clean SIGTERM exit as `failed`, so `--continue` finds no session

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?

When a claude remote-control server is stopped with Ctrl+C, the shutdown path mishandles session teardown in two connected ways, and the result is that the session cannot be resumed.

1. The archive request is sent with an ID that does not exist. The work is tracked throughout the session as cse_..., but the archive call is issued against session_... with the same suffix. The prefix appears to be swapped rather than the real session ID being used. The server has no such record, and the CLI prints Failed to archive session <id>: not found. No response line is logged for this call at all — unlike every other API call in the shutdown sequence — and the bridge proceeds to deregister the environment 160 ms later, so the failure is never checked.

2. A clean SIGTERM exit is recorded as a failure. The shutdown path sends SIGTERM itself, the child exits with code 143 (128 + 15, the expected value), and the session is then logged as exited status=failed. Because the exit is booked as a failure, no resumable record appears to be written for the directory, and claude remote-control --continue afterwards reports No recent session found in this directory or its worktrees — well inside the documented ~4 hour resume window.

Net effect: Remote Control sessions cannot be resumed after the server is stopped, which the documentation says should work. A subsequent bare claude remote-control starts at Capacity: 0/32 with no prior session, and each launch registers a new env_..., deregistering the previous one.

I've filed these together because they occur in the same shutdown sequence and share one debug log; happy to split them if you'd prefer them tracked separately.

What Should Happen?

• The archive request is sent with the session's real ID and succeeds — and its result is checked before the environment is deregistered.
• A SIGTERM exit requested by the shutdown path is recorded as a normal termination, not as failed.
• claude remote-control --continue brings back the session the server started with, per the "Resume sessions after stopping the server" section of the Remote Control docs.

Error Messages/Logs

# On Ctrl+C:
Failed to archive session <id>: not found

# Then, from the same directory:
$ claude remote-control --continue
Error: No recent session found in this directory or its worktrees.Run `claude remote-control` to start a new one.

# Debug log (--debug-file). Session IDs redacted where they appeared as
# sessionId=; work and environment IDs left intact to show the mismatch.
[DEBUG] [bridge:shutdown] SIGINT received, shutting down
[DEBUG] [bridge:shutdown] Shutting down 1 active session(s)
[DEBUG] [bridge:shutdown] Sending SIGTERM to sessionId=[REDACTED]
[DEBUG] [bridge:session] Sending SIGTERM to sessionId=[REDACTED] pid=6140
[DEBUG] [bridge:api] POST .../work/cse_01EyEFXEurTG7ZeAfY4JdmJ1/stop force=true
[DEBUG] [bridge:session] sessionId=[REDACTED] failed exit_code=143 pid=6140
[DEBUG] [bridge:session] sessionId=[REDACTED] workId=cse_01EyEFXEurTG7ZeAfY4JdmJ1 exited status=failed duration=18s
[DEBUG] [bridge:api] POST .../work/cse_01EyEFXEurTG7ZeAfY4JdmJ1/stop force=false
[DEBUG] [bridge:api] POST .../work/cse_01EyEFXEurTG7ZeAfY4JdmJ1/stop -> 200
[DEBUG] [bridge:api] POST .../work/cse_01EyEFXEurTG7ZeAfY4JdmJ1/stop -> 200
[DEBUG] [bridge:work] stopWork succeeded for workId=cse_01EyEFXEurTG7ZeAfY4JdmJ1 on attempt 1/3
[DEBUG] [bridge:shutdown] Archiving 1 session(s)
[DEBUG] [bridge:api] POST /v1/sessions/session_01EyEFXEurTG7ZeAfY4JdmJ1/archive
[DEBUG] [bridge:api] DELETE /v1/environments/bridge/env_016rcNkcwuHVxjejtddjDMXm
[DEBUG] [bridge:api] DELETE /v1/environments/bridge/env_016rcNkcwuHVxjejtddjDMXm -> 200
[DEBUG] [bridge:api] DELETE /v1/environments/bridge/env_016rcNkcwuHVxjejtddjDMXm -> 200
[DEBUG] [bridge:shutdown] Environment deregistered, bridge offline

# The two lines to compare -- same suffix 01EyEFXEurTG7ZeAfY4JdmJ1, different prefix:
POST .../work/cse_01EyEFXEurTG7ZeAfY4JdmJ1/stop -> 200
POST /v1/sessions/session_01EyEFXEurTG7ZeAfY4JdmJ1/archive       (no response logged)

Steps to Reproduce

1. cd into a git project directory and accept the workspace trust dialog by running claude once.
2. Start a server:

``bash
claude remote-control --permission-mode acceptEdits --debug-file ~/rc.log
``

1. Open the printed claude.ai/code?environment=... URL. The server moves to Connected · Capacity: 1/32.
2. Send one message so the session has history.
3. Stop the server with Ctrl+C.
4. Observe Failed to archive session <id>: not found in the terminal.
5. From the same directory, run:

``bash
claude remote-control --continue
`
Observe No recent session found in this directory or its worktrees`.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.258 (Claude Code)

Platform

Anthropic API (claude.ai subscription via /login, not an API key)

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

• Platform detail: macOS on Apple silicon (Mac mini), zsh, spawn mode same-dir (default).
• No ANTHROPIC_BASE_URL, CLAUDE_CODE_USE_BEDROCK, DISABLE_TELEMETRY, DO_NOT_TRACK, DISABLE_GROWTHBOOK, or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC set. Workspace trust accepted in the project directory.
• Reproduced across several launches with and without --permission-mode bypassPermissions, and with --create-session-in-dir passed explicitly. Same result each time.
• --session-id <id> was not tested with a valid claude.ai session ID, since the session is gone from the active list by the time the error appears.
• Possibly related to the archival-on-exit work referenced in #50147.
• Related but distinct: #87877 (no way to archive/clean up disconnected sessions on claude.ai).
• Workaround: run the server inside tmux and detach instead of stopping it, so the process stays alive and the shutdown path is never entered.