[BUG] "Can’t reach your computer" and "Remote Control host unreachable (computer_unreachable)") Eight Defects Related to Stealth Restart of Desktop App: Hidden Relaunch for Updates Silently Destroys Running Sessions

Bug: Stealth Restart Feature Destroys Running Sessions.

Nine Defects, Now Filed Individually. This Issue Is The Umbrella.

Initial Symptom: Sessions suddenly stop working and display this notice:

"Can’t reach your computer
It may be asleep or offline. This session will reconnect when it’s back.
Remote Control host unreachable (computer_unreachable)

If you are encountering this, see the bottom of this report for a way to recover your lost sessions.

--

Product: Claude Desktop (Claude Code desktop app)
App version: 1.37937.3 (bundled CLI 2.1.246)
Platform: Windows 11 Pro 10.0.26200, x64
Reported: 2026-08-27
Frequency: at least four times in five days (2026-08-23 to 2026-08-27), and again on 2026-08-29

The defects, each now its own issue

The eight defects originally reported here have been split into separate issues so each can be
triaged and closed on its own. A ninth was then carved out of defect 8, once the evidence showed it
is reachable with no restart involved.

This issue stays as the umbrella. It keeps the summary, the shared context, the impact, and the
session-recovery addendum at the bottom. The per-defect evidence has moved.

| Defect | Issue | What it is |
|---|---|---|
| 1 | #90867 | The update restart kills running sessions. The relaunch restores the window, not the sessions. Core defect. |
| 2 | #90868 | The relaunch does not preserve CLAUDE_CONFIG_DIR, so sessions register into the default config directory. |
| 3 | #90869 | Every installed profile restarts at once, because their update timers stay in lockstep. |
| 4 | #90870 | The restart fires without user action, even with an update banner staged and unactioned. |
| 5 | #90871 | No update policy downloads an update and waits for the user to install it. |
| 6 | #90872 | The restart fires long before the autoUpdaterEnforcementHours deadline. |
| 7 | #90873 | disableAutoUpdates also hides Help > Check for Updates, removing the manual update path. |
| 8 | #90874 | Local sessions are auto-registered with the cloud Remote Control bridge, with no opt-in step. |
| 9 | #90877 | A session card renders as live when no process backs it, and the failure is reported as computer_unreachable. Reachable with no restart involved. |

Defects 1 to 7 are the update restart and its policy surface. Defect 8 is why the cloud bridge is in
the picture at all. Defect 9 is the card and the error message, and it is the one that fires without
any restart, so it is worth reading on its own.

The updater mechanism underneath defects 1 to 7 is filed separately as #86556: a staged Squirrel
build is applied on any relaunch, not only on the "Relaunch to update" consent gate. That explains
why the relaunch happens without the user agreeing to it. This report covers what the relaunch then
costs.

Summary

The desktop app restarts itself to apply an update. Its "stealth relaunch" restores the window and
navigation history, but it does not restart the Claude Code CLI child processes that the quit
killed.

The sidebar session cards survive, because those records live on the server. So the sessions look
present and healthy after the restart. Opening one and sending a message fails with
Remote Control host unreachable (computer_unreachable).

The restart is designed to be invisible. That is what makes it harmful: the user has no signal that
the processes behind their sessions are gone.

One such restart killed nine running sessions. It happened again five days later, and took another
nine.

This is the core defect, filed as #90867. An unattended restart destroys in-flight work with no
warning, no consent, and no way to resume from inside the app. The cost is real: lost session
context, hours of re-establishing state, and the paid tokens spent rebuilding what the restart threw
away. Everything else in this report is secondary to that.

Version churn driving this

Five versions in four days, each a restart opportunity:

1.25927.0  ->  1.34493.1   (2026-08-23 / 08-24)
1.34493.1  ->  1.37937.0   (2026-08-25)
              1.37937.1    (downloaded 2026-08-25 21:48)
           ->  1.37937.3   (2026-08-26)

The 2026-08-29 recurrence did not need any of it. The app version was unchanged at 1.37937.3 across
that one, so app-version churn is not a necessary condition. Details in #90867.

Impact

• Nine running sessions destroyed in a single restart, with no warning and no recovery path inside

the app. Twice, five days apart.

• Session cards remain in the sidebar and appear healthy. Clicking one and sending a message returns

computer_unreachable. There is no indication the process is gone.

• Sessions become unrecoverable from the app because the config directory moved. The transcripts

survive on disk and can be resumed from a terminal with claude --resume <id>, but only if the
user knows which config directory to point at.

• A session killed before its first turn writes no transcript at all, so nothing survives to rebuild

it from. Three sessions were lost that way on 2026-08-29.

• Multiple unrequested app instances accumulate.
• Real cost to the user: destroyed work, hours spent diagnosing why sessions were unreachable, and

paid tokens consumed rebuilding context that the restart discarded. None of it was recoverable
through the app.

Expected behavior

| # | Ask | Defect issue |
|---|---|---|
| 1 | Do not restart for an update while sessions are running, or restore them afterwards. | #90867 |
| 2 | If a restart must happen, tell the user first, and say what will be closed. | #90867, #90870 |
| 3 | Preserve the launch environment across the relaunch, CLAUDE_CONFIG_DIR included. | #90868 |
| 4 | Show a session card as dead when its host process is gone, rather than failing on send. | #90877 |
| 5 | Stagger or coordinate restarts across profiles instead of restarting all of them. | #90869 |
| 6 | Offer an update policy that downloads and waits, and keep the manual update path visible when auto-updates are off. | #90871, #90873 |
| 7 | Make Remote Control registration for purely local sessions opt-in, or at least visible. | #90874 |

How to reproduce

1. Run the desktop app under two or more profiles, each with its own --user-data-dir and

CLAUDE_CONFIG_DIR.

1. Start several Claude Code sessions in each.
2. Leave them running while an update lands.
3. After the restart, note that the window looks unchanged and the session cards are still listed.

Open one and send a message.

Observed: Remote Control host unreachable (computer_unreachable), and new sessions now register
into the default config directory.

Defect 9 (#90877) has a much shorter reproduction that needs no update and no restart: start a
claude --bg session with a prompt it can answer in one turn, let it exit, and look at its card.

Session Recovery Method

Addendum: how one killed session was recovered by hand, and what that implies

A session destroyed by the restart in defect 1 was recovered manually and is running
again with its full history. The method is written up here because of what it shows: the
data needed to rebuild a killed session survives the restart intact, and the app adopts a
reconstructed record without complaint. A built-in recovery looks like small work.

The state to recover from

Session "CCD replacement sessions method", CLI session 17e646c4-.... Its process was
killed when the app quit. Afterwards:

| Piece | State |
|---|---|
| CLI process | dead |
| Named pipe cc-msg-... | gone |
| CLI transcript, 727 KB, 151 messages | intact, in the pre-restart config dir |
| Sidebar card | present, server-side, no local session behind it |
| App-side session record | missing from the profile's store |
| Worktree, clean, on its branch | present, but not in the app's worktree registry |

Two things were missing: the app record, and the transcript's presence in the config
directory the relaunched app reads. The second is defect 2. The transcript was in
\.claude\projects\ because the pre-restart app had no CLAUDE_CONFIG_DIR, while the
relaunched app reads \.claude-account-5\projects\.

The reconstruction, three files

1. Put the transcript where the current config dir expects it. Same encoded-cwd
folder name, straight copy. The original is left untouched as a fallback.

C:\Users\<user>\.claude\projects\<encoded-cwd>\17e646c4-....jsonl
  -> C:\Users\<user>\.claude-account-5\projects\<encoded-cwd>\17e646c4-....jsonl

2. Write an app-side session record into the profile store, with a fresh local_
id and cliSessionId pointing at the surviving transcript:

.claude-desktop-5\claude-code-sessions\<accountUuid>\<orgUuid>\local_<new-uuid>.json

Its key set was copied field for field from a healthy record in the same store. The
fields that carry real information are few:

| Field | Value | Where it came from |
|---|---|---|
| cliSessionId | 17e646c4-... | the transcript filename |
| cwd / worktreePath / worktreeName | the worktree | cwd field inside the transcript |
| branch | claude/ccd-replacement-... | gitBranch field inside the transcript |
| title | "CCD replacement sessions method" | the session's first user message |
| createdAt / lastActivityAt | epoch ms | session registry, transcript mtime |
| bridgeSessionIds | [] | left deliberately empty |

Everything else was structural defaults. Every value that mattered was derivable from
the transcript that survived the restart.

3. Register the worktree in .claude-desktop-5\git-worktrees.json, leased to the new
session id. Without this the app treats the directory as untracked.

Ordering matters: the app rewrites git-worktrees.json on quit, so the writes have to
happen with the app closed, then the app is reopened.

Result

The app treated the reconstructed record as fully native:

2026-08-27 12:45:29 [info] [CCD] Warming session local_<new>-...
2026-08-27 12:45:29 [info] [CCD] Session local_<new>-... warmed successfully in 55ms
2026-08-27 12:45:29 [info] LocalSessions.startShellPty: sessionId=local_<new>-...
2026-08-27 12:45:56 [info] Enabling remote control for session local_<new>-...

The session appears in the sidebar, opens with all 151 messages, and is running. Its
completedTurns has since advanced from the seeded 60 to 63 and lastActivityAt is
being updated, so the app is writing to the record normally.

The part that matters most

bridgeSessionIds was written as [] on purpose, to avoid touching the orphaned cloud
card. The app populated it on its own, at 12:45:56, with the dead card's bridge id:

bridgeSessionIds: ['session_01NSuuWN...']

The app re-adopted an orphaned bridge session into a newly created local record without
being asked. So the plumbing to reattach an existing sidebar card to a rebuilt session
already exists and works. A built-in recovery would not need to create a duplicate card;
it could reclaim the one the user is already looking at.

What this suggests

Recovery needs three things, all present on disk after the restart:

1. the transcript, which survives;
2. a session record, whose every meaningful field is derivable from that transcript;
3. a worktree registration, derivable from the same source.

The gap is not missing data. It is that nothing reads the transcript back into a session
record, and that defect 2 moves the transcript out from under the relaunched app.

Two changes would close it without new UI:

• Preserve CLAUDE_CONFIG_DIR across the relaunch (defect 2). On a single-profile

install this alone makes the transcripts visible again.

• Offer recovery for a card with no local session. On opening such a card, look for a

transcript matching its CLI session id and rebuild the record from it, reusing the
existing bridge session as the app already does unprompted.

Caveats

This used undocumented internals and may break on any release. It is offered as evidence
about what is recoverable, not as a procedure to recommend to users. The one real
uncertainty going in, whether the app resumes from cliSessionId, turned out to hold.

Can’t reach your computer
It may be asleep or offline. This session will reconnect when it’s back.
detail: Remote Control host unreachable (computer_unreachable)