morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #4278] [Bug] setup can't register Claude Desktop when the MSIX build has no package-private config #1692

New issue

Closed

opened 2026-10-16 21:09:07 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-16 21:09:07 +00:00

Owner

Originally created by @myso-kr on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4278

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

rea setup --client claude_desktop refuses to touch Claude Desktop's config on my machine, even with the app fully quit and setup run from a regular terminal.

My Claude Desktop is the MSIX build, but it has never created the package-private config (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json). It just uses %APPDATA%\Claude\claude_desktop_config.json directly. The MCP servers I already have in that file load fine, and the file gets updated while the app runs.

Since there's no private file, setup can't do its comparison and bails out. Following the suggested fix (open the app once, quit, rerun) doesn't help, because the private file never shows up. So right now I can't register REA with Claude Desktop through setup at all.

Reproduction

Windows 11 x64 with Claude Desktop MSIX 2.42304.0.0. No config file under the package's LocalCache\Roaming\Claude; %APPDATA%\Claude\claude_desktop_config.json exists.
Quit Claude Desktop from the tray and check that no Claude.exe is left running.
Open PowerShell from the Start menu and run npx -y rea-agents@6.5.0 setup --client claude_desktop.
Setup refuses (output below).

Happened both times I tried: once as --dry-run from inside the app's Code tab (expected), and once from a regular terminal with the app closed.

Expected behavior

If there's no private config and the app isn't running, setup should write to the %APPDATA% file the app actually reads, or at least give me a way to override the check. The current behavior matches what docs/client-configuration.md describes, but on this build the "no file to compare" state looks permanent.

Impact and scope

Claude Desktop can't be set up via rea setup on this machine. rea doctor shows registration:claude_desktop as missing.

Workaround: with the app closed, I added mcpServers.rea to %APPDATA%\Claude\claude_desktop_config.json by hand, using the same command and env that setup writes for Claude Code. After restarting the app the entry stuck, and rea doctor --client claude_desktop reports aligned.

I haven't tried other Claude Desktop versions.

REA version

6.5.0

Runtime and platform

Node 24.18.0; Windows 11 x64; Claude Desktop MSIX 2.42304.0.0

Target and artifact context

Not applicable

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Run from a regular terminal with Claude Desktop closed:

npx -y rea-agents@6.5.0 setup --client claude_desktop

!  Claude Desktop: REA cannot tell whether Claude Desktop's MSIX package Claude_pzs8sxrjxfjjc started this process, because none of its files under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude could be compared with %APPDATA%\Claude. A running Claude Desktop would overwrite the change. Open Claude Desktop once if it has never run, quit it fully, then rerun setup from a terminal that Claude Desktop did not start.

With --json, the status is needs_human and plannedActions is empty.

Get-AppxPackage -Name '*Claude*':

Name              : Claude
Version           : 2.42304.0.0
PackageFamilyName : Claude_pzs8sxrjxfjjc
SignatureKind     : Developer

Analysis or suspected cause

My guess, not checked against the source: the docs mention testing on MSIX build 2.31226.1.0, which did write a private copy. 2.42304 doesn't seem to virtualize Roaming\Claude anymore, so the private file never appears and setup always takes the refusal branch.

Additional context

Two ideas, neither tested: when there's no private file, fall back to checking whether the packaged Claude.exe is running; or add an explicit flag like --claude-desktop-config <path> for users who confirm the app is closed.

Originally created by @myso-kr on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4278 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior `rea setup --client claude_desktop` refuses to touch Claude Desktop's config on my machine, even with the app fully quit and setup run from a regular terminal. My Claude Desktop is the MSIX build, but it has never created the package-private config (`%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json`). It just uses `%APPDATA%\Claude\claude_desktop_config.json` directly. The MCP servers I already have in that file load fine, and the file gets updated while the app runs. Since there's no private file, setup can't do its comparison and bails out. Following the suggested fix (open the app once, quit, rerun) doesn't help, because the private file never shows up. So right now I can't register REA with Claude Desktop through setup at all. ### Reproduction 1. Windows 11 x64 with Claude Desktop MSIX 2.42304.0.0. No config file under the package's `LocalCache\Roaming\Claude`; `%APPDATA%\Claude\claude_desktop_config.json` exists. 2. Quit Claude Desktop from the tray and check that no `Claude.exe` is left running. 3. Open PowerShell from the Start menu and run `npx -y rea-agents@6.5.0 setup --client claude_desktop`. 4. Setup refuses (output below). Happened both times I tried: once as `--dry-run` from inside the app's Code tab (expected), and once from a regular terminal with the app closed. ### Expected behavior If there's no private config and the app isn't running, setup should write to the `%APPDATA%` file the app actually reads, or at least give me a way to override the check. The current behavior matches what `docs/client-configuration.md` describes, but on this build the "no file to compare" state looks permanent. ### Impact and scope Claude Desktop can't be set up via `rea setup` on this machine. `rea doctor` shows `registration:claude_desktop` as missing. Workaround: with the app closed, I added `mcpServers.rea` to `%APPDATA%\Claude\claude_desktop_config.json` by hand, using the same command and env that setup writes for Claude Code. After restarting the app the entry stuck, and `rea doctor --client claude_desktop` reports `aligned`. I haven't tried other Claude Desktop versions. ### REA version 6.5.0 ### Runtime and platform Node 24.18.0; Windows 11 x64; Claude Desktop MSIX 2.42304.0.0 ### Target and artifact context Not applicable ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Run from a regular terminal with Claude Desktop closed: ``` npx -y rea-agents@6.5.0 setup --client claude_desktop ``` ``` ! Claude Desktop: REA cannot tell whether Claude Desktop's MSIX package Claude_pzs8sxrjxfjjc started this process, because none of its files under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude could be compared with %APPDATA%\Claude. A running Claude Desktop would overwrite the change. Open Claude Desktop once if it has never run, quit it fully, then rerun setup from a terminal that Claude Desktop did not start. ``` With `--json`, the status is `needs_human` and `plannedActions` is empty. `Get-AppxPackage -Name '*Claude*'`: ``` Name : Claude Version : 2.42304.0.0 PackageFamilyName : Claude_pzs8sxrjxfjjc SignatureKind : Developer ``` ### Analysis or suspected cause My guess, not checked against the source: the docs mention testing on MSIX build 2.31226.1.0, which did write a private copy. 2.42304 doesn't seem to virtualize `Roaming\Claude` anymore, so the private file never appears and setup always takes the refusal branch. ### Additional context Two ideas, neither tested: when there's no private file, fall back to checking whether the packaged `Claude.exe` is running; or add an explicit flag like `--claude-desktop-config <path>` for users who confirm the app is closed.

bsakaguchi commented

2026-10-16 21:09:08 +00:00

Author

Owner

@CoreyKatzburg commented on GitHub (Oct 16, 2026):

Same issue here, with an extra data point: this happens on Claude Desktop MSIX 2.31226.1.0, the same build docs/client-configuration.md lists as verified, so it isn’t specific to newer builds.

Windows 10 Pro 22H2 (build 19045) x64, Node 26.8.1, rea-agents 6.5.0
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\ contains only Microsoft. There is no Claude\ folder.
The app reads and writes %APPDATA%\Claude\claude_desktop_config.json directly while it runs.
With all claude processes stopped and setup run from a standalone PowerShell, npx rea-agents@latest setup gives the same “cannot tell whether Claude Desktop’s MSIX package … started this process” refusal.
--client claude_code --client codex --yes registers those clients fine. Only claude_desktop is affected.
So the “no private file” state seems to depend on the environment rather than the build, and the suggested fix (open once, quit, rerun) can’t work here.

@CoreyKatzburg commented on GitHub (Oct 16, 2026): Same issue here, with an extra data point: this happens on Claude Desktop MSIX 2.31226.1.0, the same build docs/client-configuration.md lists as verified, so it isn’t specific to newer builds. Windows 10 Pro 22H2 (build 19045) x64, Node 26.8.1, rea-agents 6.5.0 %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\ contains only Microsoft\. There is no Claude\ folder. The app reads and writes %APPDATA%\Claude\claude_desktop_config.json directly while it runs. With all claude processes stopped and setup run from a standalone PowerShell, npx rea-agents@latest setup gives the same “cannot tell whether Claude Desktop’s MSIX package … started this process” refusal. --client claude_code --client codex --yes registers those clients fine. Only claude_desktop is affected. So the “no private file” state seems to depend on the environment rather than the build, and the suggested fix (open once, quit, rerun) can’t work here.

bsakaguchi closed this issue

2026-10-31 00:32:11 +00:00

bsakaguchi commented

2026-10-31 00:32:12 +00:00

Author

Owner

@mrcustsilva commented on GitHub (Oct 17, 2026):

Same state on a second machine, plus a source trace and some data that #4278 does
not include.

Environment: REA 6.5.0, source checkout at 63c65a2, run through
scripts/rea.mjs. Node 24.18.0, Windows 11 Pro 10.0.26300 x64. Claude Desktop
MSIX Claude_pzs8sxrjxfjjc 2.42304.0.0, SignatureKind: Developer.

Observed (setup run). The command below ran from an elevated PowerShell that
Claude Desktop did not start:

node C:\Users\<user>\Desktop\REA\scripts\rea.mjs setup --client claude_desktop

It refused with the same message as in #4278: "REA cannot tell whether Claude
Desktop's MSIX package Claude_pzs8sxrjxfjjc started this process, because none of
its files under …\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude could
be compared with …\AppData\Roaming\Claude …". Whether the app was running during
that run was not recorded. That does not change the outcome: see the source trace
below.

Observed (read-only checks, 2026-10-17, local time UTC−03:00). The listings
ran from a shell that Claude Desktop started. The private directory does not
exist, so there was no merged view that could hide files.

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming contains only
Claude-3p (created 2026-04-14), Claude-NativeHost (2026-10-15), Microsoft
(2026-02-20) and turborepo (2026-10-17 13:40). There is no Claude
directory. The package's roaming redirection does receive new directories.
Which process created turborepo is unknown.
%APPDATA%\Claude (created 2025-09-22) received new files while the app ran.
For example, lockfile was created at 13:54:06. claude_desktop_config.json
was created at 13:54:12 and modified at 13:54:21. config.json was created at
14:15:39.
Get-AppxPackageManifest reports:
- rescap:unvirtualizedResources
- desktop6:RegistryWriteVirtualization set to disabled
- a virtualization:FileSystemWriteVirtualization block whose only
  ExcludedDirectories are $(KnownFolder:LocalAppData)\Microsoft\Office\16.0\WEF,
  \Claude-3p, \Claude-Data and \Claude\logs
No RoamingAppData path is excluded.
With the app quit, mcpServers.rea was added by hand to
%APPDATA%\Claude\claude_desktop_config.json. After the app restarted,
%LOCALAPPDATA%\Claude\logs\mcp.log recorded
2026-10-17T17:28:39.034Z [info] [rea] Server started and connected successfully.
No private copy exists, so the app read the %APPDATA% file. This matches the
configPath that REA itself resolves (see below).

Source trace (source-derived, not run).

ClaudeDesktopConfigLocation.ts#L93-L106:
the package container exists, there is no private copy and there is an
AppData copy, so configPath resolves to the %APPDATA% file. REA already
agrees that the app reads that file.
ClaudeDesktopConfigLocation.ts#L136-L155:
with no private config, processView lists privateDirectory. A missing
directory throws ENOENT, which the catch at L151-L155 maps to "unknown".
ENOENT is not separated from other errors here. present() at
L182-L186
does treat a missing path as absent.
SupportedClients.ts#L283-L293:
registrationWriteBlocker lets only "direct" through (L288). "unknown"
produces the message at L292. Its callers are
SetupClientConfiguration.ts:435 (setup) and Uninstall.ts:230 (uninstall),
so uninstall should be blocked too. I did not run uninstall.
None of these inputs depend on whether Claude Desktop is running. The
remediation relies on the premise in the
doc comment at L123-L128
("Claude Desktop saves its user data there while it runs") and in
docs/client-configuration.md L78-L80. On this machine the running app saves
to the real %APPDATA%\Claude instead.
The refusal is encoded as expected behavior in two tests:
- tests/boundary/filesystem/claudeDesktopClientConfiguration.test.ts#L134-L153
  ("uses AppData while the MSIX package has no private copy") asserts
  processView: "unknown" and the "Open Claude Desktop once…" remediation.
- ClaudeDesktopConfigLocation.test.ts L139-L148 asserts "unknown" when the
  package has no private files.
The tests treat this state as transient. On this build and host it is
permanent.

Unknown or hypothesis (not verified):

Why the runtime does not redirect writes under Roaming\Claude here is
NOT_ENOUGH_INFO. The manifest does not exclude that directory. A
%APPDATA%\Claude directory that existed before the package was installed is
one candidate. The package install date was not available because
Get-AppxPackage returned an empty InstallDate.
Whether the app would read a private copy if one were created by hand is
NOT_ENOUGH_INFO. It was not tested.
Proposed checks, none run: reproduce on a clean profile with no prior
%APPDATA%\Claude, and compare it with a profile that has that directory.

@mrcustsilva commented on GitHub (Oct 17, 2026): Same state on a second machine, plus a source trace and some data that #4278 does not include. **Environment:** REA 6.5.0, source checkout at `63c65a2`, run through `scripts/rea.mjs`. Node 24.18.0, Windows 11 Pro 10.0.26300 x64. Claude Desktop MSIX `Claude_pzs8sxrjxfjjc` 2.42304.0.0, `SignatureKind: Developer`. **Observed (setup run).** The command below ran from an elevated PowerShell that Claude Desktop did not start: ``` node C:\Users\<user>\Desktop\REA\scripts\rea.mjs setup --client claude_desktop ``` It refused with the same message as in #4278: "REA cannot tell whether Claude Desktop's MSIX package Claude_pzs8sxrjxfjjc started this process, because none of its files under …\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude could be compared with …\AppData\Roaming\Claude …". Whether the app was running during that run was not recorded. That does not change the outcome: see the source trace below. **Observed (read-only checks, 2026-10-17, local time UTC−03:00).** The listings ran from a shell that Claude Desktop started. The private directory does not exist, so there was no merged view that could hide files. - `%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming` contains only `Claude-3p` (created 2026-04-14), `Claude-NativeHost` (2026-10-15), `Microsoft` (2026-02-20) and `turborepo` (2026-10-17 13:40). **There is no `Claude` directory.** The package's roaming redirection does receive new directories. Which process created `turborepo` is unknown. - `%APPDATA%\Claude` (created 2025-09-22) received new files while the app ran. For example, `lockfile` was created at 13:54:06. `claude_desktop_config.json` was created at 13:54:12 and modified at 13:54:21. `config.json` was created at 14:15:39. - `Get-AppxPackageManifest` reports: - `rescap:unvirtualizedResources` - `desktop6:RegistryWriteVirtualization` set to `disabled` - a `virtualization:FileSystemWriteVirtualization` block whose only `ExcludedDirectories` are `$(KnownFolder:LocalAppData)\Microsoft\Office\16.0\WEF`, `\Claude-3p`, `\Claude-Data` and `\Claude\logs` No `RoamingAppData` path is excluded. - With the app quit, `mcpServers.rea` was added by hand to `%APPDATA%\Claude\claude_desktop_config.json`. After the app restarted, `%LOCALAPPDATA%\Claude\logs\mcp.log` recorded `2026-10-17T17:28:39.034Z [info] [rea] Server started and connected successfully`. No private copy exists, so the app read the `%APPDATA%` file. This matches the `configPath` that REA itself resolves (see below). **Source trace (source-derived, not run).** 1. [`ClaudeDesktopConfigLocation.ts#L93-L106`](https://github.com/morluto/rea/blob/63c65a22430a4bbc0c1807a0298edb867775001f/src/application/ClaudeDesktopConfigLocation.ts#L93-L106): the package container exists, there is no private copy and there is an AppData copy, so `configPath` resolves to the `%APPDATA%` file. REA already agrees that the app reads that file. 2. [`ClaudeDesktopConfigLocation.ts#L136-L155`](https://github.com/morluto/rea/blob/63c65a22430a4bbc0c1807a0298edb867775001f/src/application/ClaudeDesktopConfigLocation.ts#L136-L155): with no private config, `processView` lists `privateDirectory`. A missing directory throws `ENOENT`, which the catch at L151-L155 maps to `"unknown"`. `ENOENT` is not separated from other errors here. `present()` at [L182-L186](https://github.com/morluto/rea/blob/63c65a22430a4bbc0c1807a0298edb867775001f/src/application/ClaudeDesktopConfigLocation.ts#L182-L186) does treat a missing path as absent. 3. [`SupportedClients.ts#L283-L293`](https://github.com/morluto/rea/blob/63c65a22430a4bbc0c1807a0298edb867775001f/src/application/SupportedClients.ts#L283-L293): `registrationWriteBlocker` lets only `"direct"` through (L288). `"unknown"` produces the message at L292. Its callers are `SetupClientConfiguration.ts:435` (setup) and `Uninstall.ts:230` (uninstall), so uninstall should be blocked too. I did not run uninstall. 4. None of these inputs depend on whether Claude Desktop is running. The remediation relies on the premise in the [doc comment at L123-L128](https://github.com/morluto/rea/blob/63c65a22430a4bbc0c1807a0298edb867775001f/src/application/ClaudeDesktopConfigLocation.ts#L123-L128) ("Claude Desktop saves its user data there while it runs") and in `docs/client-configuration.md` L78-L80. On this machine the running app saves to the real `%APPDATA%\Claude` instead. 5. The refusal is encoded as expected behavior in two tests: - [`tests/boundary/filesystem/claudeDesktopClientConfiguration.test.ts#L134-L153`](https://github.com/morluto/rea/blob/63c65a22430a4bbc0c1807a0298edb867775001f/tests/boundary/filesystem/claudeDesktopClientConfiguration.test.ts#L134-L153) ("uses AppData while the MSIX package has no private copy") asserts `processView: "unknown"` and the "Open Claude Desktop once…" remediation. - `ClaudeDesktopConfigLocation.test.ts` L139-L148 asserts `"unknown"` when the package has no private files. The tests treat this state as transient. On this build and host it is permanent. **Unknown or hypothesis (not verified):** - Why the runtime does not redirect writes under `Roaming\Claude` here is NOT_ENOUGH_INFO. The manifest does not exclude that directory. A `%APPDATA%\Claude` directory that existed before the package was installed is one candidate. The package install date was not available because `Get-AppxPackage` returned an empty `InstallDate`. - Whether the app would read a private copy if one were created by hand is NOT_ENOUGH_INFO. It was not tested. - Proposed checks, none run: reproduce on a clean profile with no prior `%APPDATA%\Claude`, and compare it with a profile that has that directory.

bsakaguchi referenced this issue

2026-10-31 00:54:44 +00:00

[PR #1692] [CLOSED] fix(windows): keep one separator when a runtime parent is a drive root #4756

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1692

No description provided.

Rows
Columns