Update relaunch does not preserve CLAUDE_CONFIG_DIR, so sessions register into the default config directory

Status Open
Reported on v2.1.246
Maintainer reply None cached
Activity 0 comments · opened Aug 31, 2026

Split out of anthropics/claude-code#90172, which reports eight interconnected defects arising from
one root cause: the desktop app restarts itself to apply an update and destroys the running Claude
Code sessions. That issue holds the shared context and the manual recovery addendum. This is
defect 2 of eight.

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)

The defect

The relaunched app does not inherit the environment it was originally started with.
CLAUDE_CONFIG_DIR is lost, so CLI sessions spawned after the relaunch register into the default
~/.claude instead of the per-account config directory.

Observed on one profile, same user-data-dir across the boundary:

| Run | Launched by | Sessions registered into |
|---|---|---|
| before restart | user launcher | C:\Users\<user>\.claude-account-5 (expected) |
| after update restart | app itself | C:\Users\<user>\.claude (wrong) |

This matters for multi-account setups. Each account normally gets its own --user-data-dir paired
with its own CLAUDE_CONFIG_DIR. After an update restart, every profile falls back to the same
default directory and they collide in one session registry.

It also makes the sessions unrecoverable from the app. The records are written to a directory the
relaunched app no longer reads, so it cannot even find them to report a better error.

Why this is worth fixing on its own

The recovery addendum in the umbrella issue shows that a killed session can be rebuilt by hand from
its surviving CLI transcript. The largest obstacle to doing that was this defect: the transcript sat
in \.claude\projects\ because the pre-restart app had no CLAUDE_CONFIG_DIR, while the relaunched
app reads \.claude-account-5\projects\.

On a single-profile install, preserving CLAUDE_CONFIG_DIR across the relaunch alone makes the
transcripts visible to the app again.

Expected behavior

Preserve the launch environment across the relaunch, CLAUDE_CONFIG_DIR included.

How to reproduce

  1. Run the desktop app under a profile with its own --user-data-dir and its own

CLAUDE_CONFIG_DIR.

  1. Start a Claude Code session and confirm its record lands in that config directory.
  2. Leave the app running while an update lands and it restarts itself.
  3. Start a new session after the restart.

Observed: the new session registers into the default ~/.claude instead.

The nine defects

Eight were reported together in #90172, because they come from one root cause. The
ninth was carved out of defect 8 once the evidence showed it is reachable with no
restart involved. Each is filed separately so it can be triaged and closed on its own.

| 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, this issue | 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. Carved out of defect 8; reachable with no restart involved. |

Shared context, impact, and the manual session-recovery addendum stay on the umbrella
issue #90172. 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.

View original on GitHub ↗