morluto/rea

Fork 0

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

[GH-ISSUE #2196] [Windows x64] Every provider-backed operation fails with "Delete owned object by handle failed (Win32 5)" #733

New issue

Closed

opened 2026-10-15 18:27:48 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:27:48 +00:00

Owner

Originally created by @csd9178 on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2196

Before submitting

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

Area

CLI

Observed behavior

Every provider-backed operation fails before the provider is invoked. The bundled Windows native addon's self-test (binding.call("inspect", [])) throws ERROR_ACCESS_DENIED (5) while deleting its own probe directory, so loadWindowsNativeAuthority returns available:false and all provider paths fail-closed.

Command:
npx -y rea-agents@latest inspect-android-package

Output:
code: capability_unavailable
category: unsupported_provider
message: "REA Windows native controls are unavailable: Delete owned object by handle failed [%TEMP%\rea-native-probe-] (Win32 5): Access is denied."
details: provider_id=jadx, operation=inspect_android_package

Reproduction

Windows 11 x64, Node v22.22.2, non-admin.
Run: npx -y rea-agents@latest inspect-android-package <any.apk>
Also reproducible from a bare script that loads the addon directly (bypassing REA's wrapping):
const b = require(".../native/windows/build/rea-windows-x64.node");
b.call("inspect", []); // throws the error above
Every failure leaves an undeletable-by-the-addon directory in %TEMP% (found 12 across one session).

Expected behavior

inspect-android-package should return the APK's declarations and decoded manifest. More generally, provider-backed operations should not fail a self-test unrelated to the requested provider.

Impact and scope

Provider-backed capabilities are unusable on this host: Android APK inspection, all ADB operations, and native binary analysis. Installing Ghidra/IDA does not help (the failure precedes any provider invocation), and running elevated does not help (it is the share flag, not privilege).

REA version

6.4.0 (rea-agents), artifact SHA-256 c4fd9f377e567bcf15ba3fec3e0b0ed965d82b765a2adcdac49e46f14524b6d5

Runtime and platform

Node.js v22.22.2; Windows 11 build 10.0.26100 x64; process.versions.napi=10; addon manifest declares nodeApiVersion=8; non-admin user; Windows Defender only.

Target and artifact context

Local standalone APK (any). Also affected: ADB device operations, native binaries. Not affected: macOS-only features (report unsupported_host as expected).

Interface

CLI

Earliest failure stage

Request parsing or validation

Relevant output or evidence

Minimal Win32 repro (ctypes): create a dir, open a handle with DELETE access, then SetFileInformationByHandle(FileDispositionInfo):

  [noShareDelete]    access=0x10000 share=0x3 -> delete ok=0 lasterr=5 (Access is denied.)
  [withShareDelete]  access=0x10000 share=0x7 -> delete ok=1 lasterr=0 (OK)
  [readOnly+delete]  access=0x10000 share=0x1 -> delete ok=0 lasterr=5 (Access is denied.)

Leftover %TEMP%\rea-native-probe-* dirs have a normal ACL (current user + SYSTEM FullControl, protected) and ARE deletable by a plain Remove-Item - proving this is not an access-control problem.

Ruled out (all verified): MCP layer, sandbox/ACL interception, %TEMP% permissions, %TEMP% redirect/virtualization (fixed local NTFS, no reparse point), TEMP on another drive (E:\), third-party AV, missing admin rights, addon not bundled / version mismatch (present, SHA matches, PE x64 validated).

Typed outcome or recovery expected

loadWindowsNativeAuthority should return available:true; providers --json should report the affected capabilities as available; inspect-android-package should stop returning capability_unavailable.

Analysis or suspected cause

The private probe directory is created/opened with a handle that does not grant FILE_SHARE_DELETE, then deleted via that same handle. Windows rejects handle-based deletion in that combination unconditionally. This matches the addon's own strings ("Delete owned object by handle failed", "Create private object relative to its admitted parent failed") and native/windows/README.md, which documents cleanup as "removes files by handle".

Suggested fix: add FILE_SHARE_DELETE to the ShareAccess of the private-object NtCreateFile / CreateFileW calls (and/or delete through a separate handle opened with DELETE | FILE_SHARE_DELETE).

Additional context

I understand this may be host-specific; happy to run any diagnostic you'd like. Windows-native lane appears to be the newest/least-exercised path, so this could be a latent bug that passes CI on the maintainers' machines.

Originally created by @csd9178 on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2196 ### 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 CLI ### Observed behavior Every provider-backed operation fails before the provider is invoked. The bundled Windows native addon's self-test (`binding.call("inspect", [])`) throws ERROR_ACCESS_DENIED (5) while deleting its own probe directory, so loadWindowsNativeAuthority returns available:false and all provider paths fail-closed. Command: npx -y rea-agents@latest inspect-android-package <apk> Output: code: capability_unavailable category: unsupported_provider message: "REA Windows native controls are unavailable: Delete owned object by handle failed [%TEMP%\rea-native-probe-<hex>] (Win32 5): Access is denied." details: provider_id=jadx, operation=inspect_android_package ### Reproduction 1. Windows 11 x64, Node v22.22.2, non-admin. 2. Run: npx -y rea-agents@latest inspect-android-package <any.apk> 3. Also reproducible from a bare script that loads the addon directly (bypassing REA's wrapping): const b = require(".../native/windows/build/rea-windows-x64.node"); b.call("inspect", []); // throws the error above 4. Every failure leaves an undeletable-by-the-addon directory in %TEMP% (found 12 across one session). ### Expected behavior inspect-android-package should return the APK's declarations and decoded manifest. More generally, provider-backed operations should not fail a self-test unrelated to the requested provider. ### Impact and scope Provider-backed capabilities are unusable on this host: Android APK inspection, all ADB operations, and native binary analysis. Installing Ghidra/IDA does not help (the failure precedes any provider invocation), and running elevated does not help (it is the share flag, not privilege). ### REA version 6.4.0 (rea-agents), artifact SHA-256 c4fd9f377e567bcf15ba3fec3e0b0ed965d82b765a2adcdac49e46f14524b6d5 ### Runtime and platform Node.js v22.22.2; Windows 11 build 10.0.26100 x64; process.versions.napi=10; addon manifest declares nodeApiVersion=8; non-admin user; Windows Defender only. ### Target and artifact context Local standalone APK (any). Also affected: ADB device operations, native binaries. Not affected: macOS-only features (report unsupported_host as expected). ### Interface CLI ### Earliest failure stage Request parsing or validation ### Relevant output or evidence ```text Minimal Win32 repro (ctypes): create a dir, open a handle with DELETE access, then SetFileInformationByHandle(FileDispositionInfo): [noShareDelete] access=0x10000 share=0x3 -> delete ok=0 lasterr=5 (Access is denied.) [withShareDelete] access=0x10000 share=0x7 -> delete ok=1 lasterr=0 (OK) [readOnly+delete] access=0x10000 share=0x1 -> delete ok=0 lasterr=5 (Access is denied.) Leftover %TEMP%\rea-native-probe-* dirs have a normal ACL (current user + SYSTEM FullControl, protected) and ARE deletable by a plain Remove-Item - proving this is not an access-control problem. Ruled out (all verified): MCP layer, sandbox/ACL interception, %TEMP% permissions, %TEMP% redirect/virtualization (fixed local NTFS, no reparse point), TEMP on another drive (E:\), third-party AV, missing admin rights, addon not bundled / version mismatch (present, SHA matches, PE x64 validated). ``` ### Typed outcome or recovery expected loadWindowsNativeAuthority should return available:true; providers --json should report the affected capabilities as available; inspect-android-package should stop returning capability_unavailable. ### Analysis or suspected cause The private probe directory is created/opened with a handle that does not grant FILE_SHARE_DELETE, then deleted via that same handle. Windows rejects handle-based deletion in that combination unconditionally. This matches the addon's own strings ("Delete owned object by handle failed", "Create private object relative to its admitted parent failed") and native/windows/README.md, which documents cleanup as "removes files by handle". Suggested fix: add FILE_SHARE_DELETE to the ShareAccess of the private-object NtCreateFile / CreateFileW calls (and/or delete through a separate handle opened with DELETE | FILE_SHARE_DELETE). ### Additional context I understand this may be host-specific; happy to run any diagnostic you'd like. Windows-native lane appears to be the newest/least-exercised path, so this could be a latent bug that passes CI on the maintainers' machines.

bsakaguchi

2026-10-15 18:27:48 +00:00

closed this issue
added the
area: runtime

P1: high

bug
labels

bsakaguchi commented

2026-10-15 18:27:49 +00:00

Author

Owner

@kaoru0822-kitauji commented on GitHub (Oct 12, 2026):

Triage note: I couldn't reproduce this here because it needs real Windows (I'm on macOS), so I'm skipping a fix. The failure (the bundled Windows native self-test throwing Delete owned object by handle failed (Win32 5) while removing its own probe directory, which then makes every provider fail closed) looks like the same failure tracked in #1701, which is still open. Linking them so the evidence here (Windows 11 26100, Node 22.22.2, non-admin, leftover %TEMP%\rea-native-probe-* directories, and the direct binding.call("inspect", []) reproduction) is in one place.

@kaoru0822-kitauji commented on GitHub (Oct 12, 2026): Triage note: I couldn't reproduce this here because it needs real Windows (I'm on macOS), so I'm skipping a fix. The failure (the bundled Windows native self-test throwing `Delete owned object by handle failed (Win32 5)` while removing its own probe directory, which then makes every provider fail closed) looks like the same failure tracked in #1701, which is still open. Linking them so the evidence here (Windows 11 26100, Node 22.22.2, non-admin, leftover `%TEMP%\rea-native-probe-*` directories, and the direct `binding.call("inspect", [])` reproduction) is in one place.

bsakaguchi commented

2026-10-15 18:27:49 +00:00

Author

Owner

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

Verified the reported defect is addressed on main by 9b08c2b1cb.

Root cause and resolution: The Windows private-runtime cleanup could not mark owned files/directories delete-pending because handles were opened without FILE_SHARE_DELETE, yielding Win32 access denied despite ownership.

Validation: native/windows/src/filesystem.cc; Windows capability and package lane — Current-head Windows lane passed verify:windows-native:artifact, verify:windows-native with process-boundary executable, and verify:package:windows; original fix evidence records direct addon inspect plus private-runtime cleanup and residual-directory absence.

Evidence: Current 7375 Windows capability/package lane succeeded.

Verification scope: Not rerun locally; this is Windows-host evidence, not a claim that all current main CI passed.

Current main CI has separate failures under repair; this closure does not claim the complete main workflow is green.

@morluto commented on GitHub (Oct 14, 2026): Verified the reported defect is addressed on main by 9b08c2b1cbbd74631738db1ddb326592682326e8. Root cause and resolution: The Windows private-runtime cleanup could not mark owned files/directories delete-pending because handles were opened without FILE_SHARE_DELETE, yielding Win32 access denied despite ownership. Validation: `native/windows/src/filesystem.cc; Windows capability and package lane` — Current-head Windows lane passed `verify:windows-native:artifact`, `verify:windows-native` with process-boundary executable, and `verify:package:windows`; original fix evidence records direct addon inspect plus private-runtime cleanup and residual-directory absence. Evidence: Current 7375 Windows capability/package lane succeeded. Verification scope: Not rerun locally; this is Windows-host evidence, not a claim that all current main CI passed. Current main CI has separate failures under repair; this closure does not claim the complete main workflow is green.

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

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

bsakaguchi referenced this issue

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

[GH-ISSUE #4310] [Feature] Open nested Apple bundle directories (appex, framework, xpc, plug-in) as targets #1714

bsakaguchi referenced this issue

2026-10-16 21:15:37 +00:00

[PR #733] [MERGED] fix(target): explain the JavaScript directory analysis route #2201

bsakaguchi referenced this issue

2026-10-16 21:15:37 +00:00

[PR #734] [MERGED] feat(evidence): accept exact retained application references #2204