morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4432] [Bug] Claude Desktop resolution misses AnthropicPBC.Claude_* and -3p builds, so setup writes a config the app never reads #1759

New issue

Closed

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

bsakaguchi commented

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

Owner

Originally created by @Sunset1014 on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4432

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 registered mcpServers.rea in %APPDATA%\Claude\claude_desktop_config.json on this machine. The installed Claude Desktop never reads that file, so the registration had no effect: setup reported success, rea doctor --client claude_desktop reports registration:claude_desktop as ok: true / healthy pointing at that path, and the app still loaded zero user-configured MCP servers.

Two properties of this install are not covered by the current resolver or docs/client-configuration.md:

The MSIX package family is AnthropicPBC.Claude_fnn82j28hfe8t, not Claude_pzs8sxrjxfjjc. Get-AppxPackage reports Name: AnthropicPBC.Claude, Version: 2.37337.1.0, PackageFamilyName: AnthropicPBC.Claude_fnn82j28hfe8t, SignatureKind: Store; the running process is C:\Program Files\WindowsApps\AnthropicPBC.Claude_2.37337.1.0_x64__fnn82j28hfe8t\app\Claude.exe.
The app runs the 3P deployment (-3p), so its configuration lives under a Claude-3p userData directory. It reads and writes %LOCALAPPDATA%\Claude-3p\claude_desktop_config.json.

Because the family name fails REA's anchored CLAUDE_PACKAGE_FAMILY regex, the directory is filtered out before the "unrecognized publisher" guard can run, so REA silently falls back to the %APPDATA% file instead of reporting that it cannot establish which file the app reads.

Reproduction

(observed state) Windows 11 x64 with the Store/MSIX Claude Desktop 2.37337.1.0 (PackageFamilyName: AnthropicPBC.Claude_fnn82j28hfe8t), running as a 3P deployment. %LOCALAPPDATA%\Claude-3p\claude_desktop_config.json exists with "deploymentMode": "3p" and is rewritten by the app while it runs. %APPDATA%\Claude\claude_desktop_config.json did not exist beforehand.
rea setup for Claude Desktop on this machine created %APPDATA%\Claude\claude_desktop_config.json containing mcpServers.rea, leaving a 26-byte claude_desktop_config.json.rea.backup beside it. I did not rerun setup; I read the resulting files, their timestamps, and that sibling backup.
Fully quitting and restarting Claude Desktop produced no REA connection: the app logged no MCP Server connection requested for: rea, and %LOCALAPPDATA%\Claude-3p\claude_desktop_config.json still had no mcpServers key. rea doctor --client claude_desktop (read-only, run by me) reported registration:claude_desktop as ok: true / healthy for the %APPDATA% path.
With the app fully quit, hand-merging the same mcpServers.rea block into %LOCALAPPDATA%\Claude-3p\claude_desktop_config.json and starting the app produced Connected to rea (207 tools) in the app log.

Reproduced on one machine. Not tested on any other Claude Desktop build.

Expected behavior

When the configuration file cannot be established, setup should refuse and say so — the typed refusal docs/client-configuration.md already describes for a Claude_<publisher ID> package from another publisher — rather than assuming the app reads %APPDATA%\Claude\claude_desktop_config.json. rea doctor should then not report that registration as healthy, because a registration the app never loads is not aligned.

Either of these would also satisfy the contract: recognize AnthropicPBC.Claude_<publisher ID> and use %LOCALAPPDATA%\Claude-3p\claude_desktop_config.json for -3p builds; or add an explicit --claude-desktop-config <path> / CLAUDE_DESKTOP_CONFIG_PATH override for users who have confirmed the path.

I could not find a documented contract for a 3P (-3p) deployment; client-configuration.md names only Claude_pzs8sxrjxfjjc, C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc, and the %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude private copy. So this expectation is inferred from the documented refusal contract, not from a documented 3P rule.

Impact and scope

REA cannot be registered with this Claude Desktop at all, and the failure is silent in both directions: setup reports success and rea doctor reports the registration healthy against a file the app never reads. A user gets no signal short of reading the app's own logs.

Frequency: 100% on this install. Whether other Store/MSIX Claude Desktop builds use AnthropicPBC.Claude_*, and how widely -3p is deployed, is unknown to me.

Recovery: manual merge into the app's real config with the app fully quit; the entry then survives the app's own rewrite, because the app merges rather than replaces and preserves unknown keys such as mcpServers.

No evidence-integrity, isolation, or data-loss impact observed. REA does create %APPDATA%\Claude\claude_desktop_config.json when absent, but nothing on this install reads it.

REA version

6.5.0

Runtime and platform

Node v26.11.1; Windows 11 Pro build 26300 x64; Claude Desktop Store/MSIX 2.37337.1.0, PackageFamilyName: AnthropicPBC.Claude_fnn82j28hfe8t; Ghidra 12.1.4 (scoop).

Target and artifact context

Not applicable — Claude Desktop client configuration resolution only. No target artifact was analyzed.

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

rea doctor --client claude_desktop reports the unread file as healthy:

scope_checks[2]:
  - name: node
    ok: true
    classification: healthy
    detail: 26.11.1
  - name: "registration:claude_desktop"
    ok: true
    classification: healthy
    detail: "C:\\Users\\<user>\\AppData\\Roaming\\Claude\\claude_desktop_config.json"

The file REA wrote — %APPDATA%\Claude\claude_desktop_config.json (paths abbreviated):

{
  "mcpServers": {
    "rea": {
      "command": "<node>",
      "args": ["<...>\\rea-agents\\scripts\\rea.mjs", "mcp"],
      "env": { "GHIDRA_INSTALL_DIR": "<scoop ghidra>", "JAVA_HOME": "<scoop temurin>" }
    }
  }
}

Its sibling backup, 26 bytes — the file did not exist before:

{
  "mcpServers": {
  }
}

The file the app actually reads — %LOCALAPPDATA%\Claude-3p\claude_desktop_config.json — had no mcpServers key after setup, and is rewritten by the app itself while running:

{
  "deploymentMode": "3p",
  "coworkUserFilesPath": "<cwd>",
  "preferences": { ... }
}

That this is the app's real configuration path is confirmed by the app's own bundled main-process code in app.asar:

var HQ = "-3p", UQ = "Claude", WQ = `${UQ}${HQ}`;   // "Claude-3p"
var GQ = "claude_desktop_config.json";
function KQ(){                       // userData directory
  if (process.env.CLAUDE_USER_DATA_DIR) return app.getPath("userData");
  if (process.platform === "win32" && process.env.LOCALAPPDATA)
    return join(process.env.LOCALAPPDATA, WQ);      // %LOCALAPPDATA%\Claude-3p
  ...
}
function JQ(){ return join(process.env.APPDATA, WQ); }   // legacy: %APPDATA%\Claude-3p
function $Q(){ return join(KQ(), GQ); }                  // the config file it reads

The same bundle carries both package identities as data (Claude_pzs8sxrjxfjjc and AnthropicPBC.Claude_fnn82j28hfe8t) alongside -3p and Claude-3p in its userData-move map.

Timeline showing the silent no-op — the app starts after REA's write and still loads nothing:

15:59:21  REA writes mcpServers.rea to %APPDATA%\Claude\claude_desktop_config.json
15:59:34  Claude Desktop starts; zero user MCP servers loaded

After the manual merge plus a restart, from the app's own log:

16:09:05 [info] MCP Server connection requested for: rea
16:09:05 [info] Launching MCP Server: rea
16:09:13 [info] [LocalMcpServerManager] Connecting to rea
16:09:20 [info] [LocalMcpServerManager] rea negotiated protocol version: 2025-11-25
16:09:20 [info] [LocalMcpServerManager] Connected to rea (207 tools)

Source reference (shipped rea-agents@6.5.0, dist/application/ClaudeDesktopConfigLocation.js):

export const CLAUDE_DESKTOP_PACKAGE_FAMILY = "Claude_pzs8sxrjxfjjc";   // line 13
const CLAUDE_PACKAGE_FAMILY = /^Claude_[0-9a-hjkmnp-tv-z]{13}$/iu;     // line 15
families = fileSystem.readdir(packagesDirectory)
  .filter((name) => CLAUDE_PACKAGE_FAMILY.test(name));                 // lines 35-37
...
if (family === undefined)
  return ok({ configPath: appDataConfigPath, markerPath: appDataDirectory });  // lines 54-55

AnthropicPBC.Claude_fnn82j28hfe8t fails that anchored regex, so families is empty and the foreign guard never runs.

Missing evidence: I did not inspect the src/ checkout — these line numbers come from the published npm bundle. I did not test any other Claude Desktop build and did not exercise uninstall.

Typed outcome or recovery expected

Setup should either write to the configuration the installed app actually reads, or return the existing "cannot establish which file Claude Desktop reads" refusal instead of success. rea doctor should agree with whatever setup established: if setup wrote a file the app does not read, doctor should not classify registration:claude_desktop as healthy.

Analysis or suspected cause

Source-derived from the published bundle above, not confirmed against a source checkout: resolveWindowsClaudeDesktopLocation treats "no directory matching ^Claude_[0-9a-hjkmnp-tv-z]{13}$" as "Claude Desktop has no MSIX package", which is indistinguishable from "this is a Claude Desktop MSIX package REA does not recognize". AnthropicPBC.Claude_* collapses into the first case and silently yields the %APPDATA% fallback.

A narrower second gap: the resolver has no notion of the -3p deployment, so even a recognized family would need the Claude-3p userData suffix to find the right file.

Hypothesis only: the family name may have changed with the Store-signed build, and the 3P deployment mode adds the -3p suffix to the userData directory name.

Additional context

Distinct from, and not covered by:

#4278 — the family is recognized (Claude_pzs8sxrjxfjjc) and there is no package-private copy, so setup refuses loudly. Here the family is unrecognized and setup succeeds quietly against a file the app never reads — different root cause, opposite failure mode.
#4378 — source-only analysis of the final private-path recheck misclassifying EACCES/EPERM after an AppData selection was admitted. That branch is not reached here.
#4081 / #3408 / #4058 (Cluster A in #4330) — MCP tool schema and connector behavior after registration succeeds.
#4330 / #3537 — consolidation trackers; this report is not one of the Claude Desktop duplicates listed there.

Happy to rerun read-only checks (rea doctor, Get-AppxPackage, app log excerpts) or test a patched resolver against this install.

Originally created by @Sunset1014 on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4432 ### 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 registered `mcpServers.rea` in `%APPDATA%\Claude\claude_desktop_config.json` on this machine. The installed Claude Desktop **never reads that file**, so the registration had no effect: setup reported success, `rea doctor --client claude_desktop` reports `registration:claude_desktop` as `ok: true / healthy` pointing at that path, and the app still loaded zero user-configured MCP servers. Two properties of this install are not covered by the current resolver or `docs/client-configuration.md`: 1. **The MSIX package family is `AnthropicPBC.Claude_fnn82j28hfe8t`, not `Claude_pzs8sxrjxfjjc`.** `Get-AppxPackage` reports `Name: AnthropicPBC.Claude`, `Version: 2.37337.1.0`, `PackageFamilyName: AnthropicPBC.Claude_fnn82j28hfe8t`, `SignatureKind: Store`; the running process is `C:\Program Files\WindowsApps\AnthropicPBC.Claude_2.37337.1.0_x64__fnn82j28hfe8t\app\Claude.exe`. 2. **The app runs the 3P deployment (`-3p`), so its configuration lives under a `Claude-3p` userData directory.** It reads and writes `%LOCALAPPDATA%\Claude-3p\claude_desktop_config.json`. Because the family name fails REA's anchored `CLAUDE_PACKAGE_FAMILY` regex, the directory is filtered out *before* the "unrecognized publisher" guard can run, so REA silently falls back to the `%APPDATA%` file instead of reporting that it cannot establish which file the app reads. ### Reproduction 1. (observed state) Windows 11 x64 with the Store/MSIX Claude Desktop 2.37337.1.0 (`PackageFamilyName: AnthropicPBC.Claude_fnn82j28hfe8t`), running as a 3P deployment. `%LOCALAPPDATA%\Claude-3p\claude_desktop_config.json` exists with `"deploymentMode": "3p"` and is rewritten by the app while it runs. `%APPDATA%\Claude\claude_desktop_config.json` did not exist beforehand. 2. `rea setup` for Claude Desktop on this machine created `%APPDATA%\Claude\claude_desktop_config.json` containing `mcpServers.rea`, leaving a 26-byte `claude_desktop_config.json.rea.backup` beside it. I did not rerun setup; I read the resulting files, their timestamps, and that sibling backup. 3. Fully quitting and restarting Claude Desktop produced no REA connection: the app logged no `MCP Server connection requested for: rea`, and `%LOCALAPPDATA%\Claude-3p\claude_desktop_config.json` still had no `mcpServers` key. `rea doctor --client claude_desktop` (read-only, run by me) reported `registration:claude_desktop` as `ok: true / healthy` for the `%APPDATA%` path. 4. With the app fully quit, hand-merging the same `mcpServers.rea` block into `%LOCALAPPDATA%\Claude-3p\claude_desktop_config.json` and starting the app produced `Connected to rea (207 tools)` in the app log. Reproduced on one machine. Not tested on any other Claude Desktop build. ### Expected behavior When the configuration file cannot be established, setup should refuse and say so — the typed refusal `docs/client-configuration.md` already describes for a `Claude_<publisher ID>` package from another publisher — rather than assuming the app reads `%APPDATA%\Claude\claude_desktop_config.json`. `rea doctor` should then not report that registration as healthy, because a registration the app never loads is not aligned. Either of these would also satisfy the contract: recognize `AnthropicPBC.Claude_<publisher ID>` and use `%LOCALAPPDATA%\Claude-3p\claude_desktop_config.json` for `-3p` builds; or add an explicit `--claude-desktop-config <path>` / `CLAUDE_DESKTOP_CONFIG_PATH` override for users who have confirmed the path. I could not find a documented contract for a 3P (`-3p`) deployment; `client-configuration.md` names only `Claude_pzs8sxrjxfjjc`, `C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc`, and the `%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude` private copy. So this expectation is inferred from the documented refusal contract, not from a documented 3P rule. ### Impact and scope REA cannot be registered with this Claude Desktop at all, and the failure is silent in both directions: setup reports success and `rea doctor` reports the registration healthy against a file the app never reads. A user gets no signal short of reading the app's own logs. Frequency: 100% on this install. Whether other Store/MSIX Claude Desktop builds use `AnthropicPBC.Claude_*`, and how widely `-3p` is deployed, is unknown to me. Recovery: manual merge into the app's real config with the app fully quit; the entry then survives the app's own rewrite, because the app merges rather than replaces and preserves unknown keys such as `mcpServers`. No evidence-integrity, isolation, or data-loss impact observed. REA does create `%APPDATA%\Claude\claude_desktop_config.json` when absent, but nothing on this install reads it. ### REA version 6.5.0 ### Runtime and platform Node v26.11.1; Windows 11 Pro build 26300 x64; Claude Desktop Store/MSIX 2.37337.1.0, `PackageFamilyName: AnthropicPBC.Claude_fnn82j28hfe8t`; Ghidra 12.1.4 (scoop). ### Target and artifact context Not applicable — Claude Desktop client configuration resolution only. No target artifact was analyzed. ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence `rea doctor --client claude_desktop` reports the unread file as healthy: ``` scope_checks[2]: - name: node ok: true classification: healthy detail: 26.11.1 - name: "registration:claude_desktop" ok: true classification: healthy detail: "C:\\Users\\<user>\\AppData\\Roaming\\Claude\\claude_desktop_config.json" ``` The file REA wrote — `%APPDATA%\Claude\claude_desktop_config.json` (paths abbreviated): ```json { "mcpServers": { "rea": { "command": "<node>", "args": ["<...>\\rea-agents\\scripts\\rea.mjs", "mcp"], "env": { "GHIDRA_INSTALL_DIR": "<scoop ghidra>", "JAVA_HOME": "<scoop temurin>" } } } } ``` Its sibling backup, 26 bytes — the file did not exist before: ```json { "mcpServers": { } } ``` The file the app actually reads — `%LOCALAPPDATA%\Claude-3p\claude_desktop_config.json` — had no `mcpServers` key after setup, and is rewritten by the app itself while running: ```json { "deploymentMode": "3p", "coworkUserFilesPath": "<cwd>", "preferences": { ... } } ``` That this is the app's real configuration path is confirmed by the app's own bundled main-process code in `app.asar`: ```js var HQ = "-3p", UQ = "Claude", WQ = `${UQ}${HQ}`; // "Claude-3p" var GQ = "claude_desktop_config.json"; function KQ(){ // userData directory if (process.env.CLAUDE_USER_DATA_DIR) return app.getPath("userData"); if (process.platform === "win32" && process.env.LOCALAPPDATA) return join(process.env.LOCALAPPDATA, WQ); // %LOCALAPPDATA%\Claude-3p ... } function JQ(){ return join(process.env.APPDATA, WQ); } // legacy: %APPDATA%\Claude-3p function $Q(){ return join(KQ(), GQ); } // the config file it reads ``` The same bundle carries both package identities as data (`Claude_pzs8sxrjxfjjc` and `AnthropicPBC.Claude_fnn82j28hfe8t`) alongside `-3p` and `Claude-3p` in its userData-move map. Timeline showing the silent no-op — the app starts *after* REA's write and still loads nothing: ``` 15:59:21 REA writes mcpServers.rea to %APPDATA%\Claude\claude_desktop_config.json 15:59:34 Claude Desktop starts; zero user MCP servers loaded ``` After the manual merge plus a restart, from the app's own log: ``` 16:09:05 [info] MCP Server connection requested for: rea 16:09:05 [info] Launching MCP Server: rea 16:09:13 [info] [LocalMcpServerManager] Connecting to rea 16:09:20 [info] [LocalMcpServerManager] rea negotiated protocol version: 2025-11-25 16:09:20 [info] [LocalMcpServerManager] Connected to rea (207 tools) ``` Source reference (shipped `rea-agents@6.5.0`, `dist/application/ClaudeDesktopConfigLocation.js`): ```js export const CLAUDE_DESKTOP_PACKAGE_FAMILY = "Claude_pzs8sxrjxfjjc"; // line 13 const CLAUDE_PACKAGE_FAMILY = /^Claude_[0-9a-hjkmnp-tv-z]{13}$/iu; // line 15 families = fileSystem.readdir(packagesDirectory) .filter((name) => CLAUDE_PACKAGE_FAMILY.test(name)); // lines 35-37 ... if (family === undefined) return ok({ configPath: appDataConfigPath, markerPath: appDataDirectory }); // lines 54-55 ``` `AnthropicPBC.Claude_fnn82j28hfe8t` fails that anchored regex, so `families` is empty and the `foreign` guard never runs. Missing evidence: I did not inspect the `src/` checkout — these line numbers come from the published npm bundle. I did not test any other Claude Desktop build and did not exercise `uninstall`. ### Typed outcome or recovery expected Setup should either write to the configuration the installed app actually reads, or return the existing "cannot establish which file Claude Desktop reads" refusal instead of success. `rea doctor` should agree with whatever setup established: if setup wrote a file the app does not read, doctor should not classify `registration:claude_desktop` as healthy. ### Analysis or suspected cause Source-derived from the published bundle above, not confirmed against a source checkout: `resolveWindowsClaudeDesktopLocation` treats "no directory matching `^Claude_[0-9a-hjkmnp-tv-z]{13}$`" as "Claude Desktop has no MSIX package", which is indistinguishable from "this is a Claude Desktop MSIX package REA does not recognize". `AnthropicPBC.Claude_*` collapses into the first case and silently yields the `%APPDATA%` fallback. A narrower second gap: the resolver has no notion of the `-3p` deployment, so even a recognized family would need the `Claude-3p` userData suffix to find the right file. Hypothesis only: the family name may have changed with the Store-signed build, and the 3P deployment mode adds the `-3p` suffix to the userData directory name. ### Additional context Distinct from, and not covered by: - **#4278** — the family *is* recognized (`Claude_pzs8sxrjxfjjc`) and there is no package-private copy, so setup **refuses loudly**. Here the family is unrecognized and setup **succeeds quietly** against a file the app never reads — different root cause, opposite failure mode. - **#4378** — source-only analysis of the final private-path recheck misclassifying `EACCES`/`EPERM` after an AppData selection was admitted. That branch is not reached here. - **#4081** / **#3408** / **#4058** (Cluster A in #4330) — MCP tool schema and connector behavior *after* registration succeeds. - **#4330** / **#3537** — consolidation trackers; this report is not one of the Claude Desktop duplicates listed there. Happy to rerun read-only checks (`rea doctor`, `Get-AppxPackage`, app log excerpts) or test a patched resolver against this install.

bsakaguchi commented

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

Author

Owner

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

Cross-referencing with sibling issues in Cluster J (Claude Setup & Configuration Discovery Edge Cases): #4278 (setup can't register Claude Desktop when the MSIX build has no package-private config) and #4262. Both issues document Windows Claude Desktop MSIX virtualized config discovery failures where rea setup targets the default roaming path instead of the app's effective package storage (AnthropicPBC.Claude_*).

Indexed under Cluster J in consolidation tracker #4330.

@matbrgz commented on GitHub (Oct 16, 2026): Cross-referencing with sibling issues in **Cluster J (Claude Setup & Configuration Discovery Edge Cases)**: #4278 (`setup can't register Claude Desktop when the MSIX build has no package-private config`) and #4262. Both issues document Windows Claude Desktop MSIX virtualized config discovery failures where `rea setup` targets the default roaming path instead of the app's effective package storage (`AnthropicPBC.Claude_*`). Indexed under Cluster J in consolidation tracker #4330.

bsakaguchi referenced this issue

2026-10-17 21:01:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

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

Revalidated and closing as fixed on main abb54ce3743dd51a54304833a6e081b89243a5e8. The runtime fixes were already published in 9abdad335; this reconciliation adds missing focused regressions in abb54ce37.

9abdad335 recognizes the reported AnthropicPBC.Claude_fnn82j28hfe8t family spelling as an unrecognized deployment and refuses AppData fallback. This satisfies the report's requested refusal contract; it does not add native3P support. Added direct family controls and a filesystem/consumer control proving setup fails before mutation and shared doctor registration inspection returns invalid even when an AppData registration already exists. The reported family controls fail on pre-fix6d5281407; the existing generic unknown-publisher guard still passes there.

Validation:82 tests across four configuration/CLI files passed. Seven newly checked-in controls ran against pre-fix6d5281407: six failed for the expected original defects and one existing-behavior guard passed; all seven pass now. Typecheck/lint, formatting, test discovery (1563files exactly once) and pre-push checks passed. Related header/skill/doctor reconciliation added186passing checks across nine other files.

Scope: macOS arm64 / Node24.18.0; controlled native files, source/platform-selected Windows adapters and real REA CLI commands. No native Windows Claude app,3P deployment, Windows/Linux permission fault or provider/target execution was verified. No full-suite or performance improvement claim.

@morluto commented on GitHub (Oct 17, 2026): Revalidated and closing as fixed on main `abb54ce3743dd51a54304833a6e081b89243a5e8`. The runtime fixes were already published in `9abdad335`; this reconciliation adds missing focused regressions in `abb54ce37`. 9abdad335 recognizes the reported AnthropicPBC.Claude_fnn82j28hfe8t family spelling as an unrecognized deployment and refuses AppData fallback. This satisfies the report's requested refusal contract; it does not add native3P support. Added direct family controls and a filesystem/consumer control proving setup fails before mutation and shared doctor registration inspection returns invalid even when an AppData registration already exists. The reported family controls fail on pre-fix6d5281407; the existing generic unknown-publisher guard still passes there. Validation:82 tests across four configuration/CLI files passed. Seven newly checked-in controls ran against pre-fix6d5281407: six failed for the expected original defects and one existing-behavior guard passed; all seven pass now. Typecheck/lint, formatting, test discovery (1563files exactly once) and pre-push checks passed. Related header/skill/doctor reconciliation added186passing checks across nine other files. Scope: macOS arm64 / Node24.18.0; controlled native files, source/platform-selected Windows adapters and real REA CLI commands. No native Windows Claude app,3P deployment, Windows/Linux permission fault or provider/target execution was verified. No full-suite or performance improvement claim.

bsakaguchi referenced this issue

2026-10-31 00:55:10 +00:00

[PR #1759] [MERGED] fix(javascript): index repeated graph observations before final sorting #4799

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#1759

No description provided.

Rows
Columns