morluto/rea

Fork 0

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

[GH-ISSUE #2204] [Bug] Ghidra provider stays unavailable when JAVA_HOME contains non-ASCII characters on Windows #737

New issue

Closed

opened 2026-10-15 18:27:50 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

Provider or capability discovery

Interface

CLI

Earliest failure stage

Setup or provider admission

REA version

6.4.0 (rea-agents, npm global install; server_identity.catalog reports 170 MCP tools / 127 CLI commands)

Runtime and platform

Node 24.15.0; Windows 11 Home China 10.0.26200 x64; Ghidra 12.1.4 (Windows Ghidra P0);
Eclipse Temurin JDK 21.0.12.1 (full JDK, 64-bit)

Target and artifact context

Not applicable — the failure occurs during provider admission, before any target is selected.
(For completeness: a PE x86-64 target does analyze successfully once the provider is admitted,
including when the target itself sits under a non-ASCII path.)

Observed behavior

rea doctor classifies a full JDK as a runtime-only installation, which makes the Ghidra
provider unavailable, when JAVA_HOME contains non-ASCII characters:

[FAIL] java
   code: unsupported_version
   detail: 21.0.12.1; 64-bit; runtime only; D:\REA逆向\tools\jdk-21.0.12.1+1; accepted a 64-bit full JDK 21 or newer
   fix: Update JAVA_HOME to the root of a 64-bit full JDK 21 or newer installation.

The identical JDK, moved to an ASCII path, passes:

[OK] java
   detail: 21.0.12.1; 64-bit; JDK; D:\tools\jdk-21.0.12.1+1; accepted a 64-bit full JDK 21 or newer

In both cases every other Ghidra check passes (configuration, platform, architecture,
installation, version, headless, native_decompiler, native_authority), and
rea analyze works normally once the provider is admitted.

Reproduction

Extract a full JDK 21 to a directory whose path contains non-ASCII characters, for example
D:\REA逆向\tools\jdk-21.0.12.1+1. Extract Ghidra 12.1.4 to any path.
Set JAVA_HOME to the JDK path and GHIDRA_INSTALL_DIR to the Ghidra path.
Run rea doctor --json. The Ghidra candidate is reported unavailable, and the java check is
ok: false with detail "runtime only" (see above).
Move the same JDK directory to an ASCII path (D:\tools\jdk-21.0.12.1+1), point JAVA_HOME at
it, and rerun rea doctor --json. The java check is now ok: true, detail "JDK", and the
Ghidra candidate status becomes available.

Reduced reproduction of the underlying probe (no REA involved), run on a Chinese-locale Windows host:

const { spawnSync } = require('child_process');
const java = process.env.JAVA_HOME + '/bin/java.exe';
const grab = (out) => (/^\s*java\.home\s*=\s*(.+?)\s*$/mu.exec(out)?.[1]) ?? null;
const run = (extra) => {
  const r = spawnSync(java, [...extra, '-XX:-UsePerfData', '-XshowSettings:properties', '-version'],
    { encoding: 'utf8', windowsHide: true, maxBuffer: Infinity });
  return grab(`${r.stdout ?? ''}\n${r.stderr ?? ''}`);
};
console.log('default:', JSON.stringify(run([])));
console.log('utf8   :', JSON.stringify(run(['-Dstdout.encoding=UTF-8', '-Dstderr.encoding=UTF-8'])));

Output:

default: "D:\\REA\uFFFD\uFFFD\\tools\\jdk-21.0.12.1+1"
utf8   : "D:\\REA\u9006\u5411\\tools\\jdk-21.0.12.1+1"

fs.accessSync(<java.home> + '/bin/javac.exe', fs.constants.X_OK) throws ENOENT for the first
and succeeds for the second.

Expected behavior

A java.home containing non-ASCII characters should still be classified as a JDK, exactly as one
on an ASCII path is. The probe should either request UTF-8 output from the child JVM explicitly, or
decode the child's output using the platform's active codepage instead of assuming UTF-8.

java -Dstdout.encoding=UTF-8 -Dstderr.encoding=UTF-8 demonstrably yields a correctly decoded
java.home on the same host and JDK, and Java 21 is already the floor for Ghidra 12.1.4, so this
does not widen the runtime requirement.

Impact and scope

On any Windows host whose JDK path contains non-ASCII characters, the Ghidra provider cannot be
admitted at all: rea doctor reports it unavailable and native analysis is refused, even though
Ghidra, the JDK, and the native decompiler are installed correctly and every other check passes.

This is not limited to one locale — it affects Chinese, Japanese, Korean, Cyrillic, and any other
path with non-ASCII characters, which is common on Windows because localized user-profile and
install directories frequently contain them (here, the user's own project folder name).

Because ghidraJavaEnvironment deliberately blanks _JAVA_OPTIONS, JAVA_TOOL_OPTIONS,
JDK_JAVA_OPTIONS, and GHIDRA_JAVA_OPTIONS for the probe, there is no environment-variable
workaround: the only fix available to a user is relocating the entire JDK to an ASCII path.
That is a surprising requirement, and the resulting doctor diagnostic ("runtime only", with
remediation "update JAVA_HOME to the root of a 64-bit full JDK") actively points the user away
from the real cause — the JDK is a full JDK.

What is not affected: GHIDRA_INSTALL_DIR may contain non-ASCII characters, and analysis
targets may too — both were verified working end to end (a PE x86-64 target under a non-ASCII path
produced correct segments and a matching SHA-256). Evidence integrity, process isolation, target
handling, and recovery are unaffected; this is provider admission only.

Relevant output or evidence

rea doctor --json fragments for the two configurations are quoted under Observed behavior.
The full failing check list for the non-ASCII JAVA_HOME case:

[OK]   configuration      D:\REA逆向\tools\ghidra_12.1.4_PUBLIC
[OK]   platform           win32
[OK]   architecture       x64
[OK]   installation       ...\Ghidra\application.properties
[OK]   version            12.1.4
[OK]   headless           ...\support\analyzeHeadless.bat
[OK]   native_decompiler  ...\decompile.exe reports pe x86_64
[FAIL] java               ...; runtime only; ...; accepted a 64-bit full JDK 21 or newer

With the ASCII JDK path, the same list ends with:

[OK]   java               21.0.12.1; 64-bit; JDK; D:\tools\jdk-21.0.12.1+1; accepted ...
[OK]   native_authority   Verified Windows native Job Object, private DACL, and reparse-safe handle controls; local NTFS only.

Typed outcome or recovery expected

The java provider check should return ok: true for a full JDK regardless of the characters in
its path. If the path genuinely cannot be used, the check should report a distinct code for the
encoding or path condition rather than reusing unsupported_version, so the remediation can name
the actual problem.

Analysis or suspected cause

Hypothesis (source-derived reasoning plus a local reproduction, not maintainer-confirmed):

probeJava in src/ghidra/GhidraInstallation.ts runs

spawnSync(command, ["-XX:-UsePerfData", "-XshowSettings:properties", "-version"],
  { encoding: "utf8", env: environment, timeout: 5_000, ... })

and parses java.home out of the captured output before testing
executablePath(join(home, "bin", "javac.exe")), where a miss sets runtime: "jre" and the
java check reports unsupported_version with the detail text "runtime only".

On Windows the JVM writes -XshowSettings output using the process's active ANSI codepage
(GBK/936 on this host) unless stdout.encoding / stderr.encoding are set, so non-ASCII
characters in java.home are already mangled before Node decodes the bytes as UTF-8. The
decoded home no longer names a real directory, javac.exe is not found, and the JDK is
misclassified. Requesting UTF-8 output from the child fixes the decode, as shown above.

Other providers that shell out to Java on Windows (src/android/JadxProvider.ts also manages
JAVA_TOOL_OPTIONS / JDK_JAVA_OPTIONS) may have the same exposure; I have not tested them.

Additional context

Related but distinct: #1200 and #1222 addressed relative installation and Java paths in doctor
and setup. This is an output-decoding problem, not a path-shape problem — an absolute, valid,
full JDK path fails purely because of the characters in it.
Related: #1698 (keeping JVM warnings out of LaunchSupport output) suggests parsing a child JVM's
output is already a recognized fragile area; this is the same surface with an encoding cause.
Suggested regression test: a probeJava / doctor fixture whose java.home contains a non-ASCII
character, asserting the JDK classification and the decoded home path. A unit-level fake of the
child output (GBK-encoded bytes for a path with non-ASCII characters, decoded as UTF-8) would
pin the behavior without needing a real JDK on Windows CI.
Workaround for other affected users, until this is fixed: keep JAVA_HOME on an ASCII-only path.

Originally created by @lovecontroing on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2204 ## 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 Provider or capability discovery ## Interface CLI ## Earliest failure stage Setup or provider admission ## REA version 6.4.0 (`rea-agents`, npm global install; `server_identity.catalog` reports 170 MCP tools / 127 CLI commands) ## Runtime and platform Node 24.15.0; Windows 11 Home China 10.0.26200 x64; Ghidra 12.1.4 (Windows Ghidra P0); Eclipse Temurin JDK 21.0.12.1 (full JDK, 64-bit) ## Target and artifact context Not applicable — the failure occurs during provider admission, before any target is selected. (For completeness: a PE x86-64 target does analyze successfully once the provider is admitted, including when the target itself sits under a non-ASCII path.) ## Observed behavior `rea doctor` classifies a **full JDK** as a runtime-only installation, which makes the Ghidra provider unavailable, when `JAVA_HOME` contains non-ASCII characters: ``` [FAIL] java code: unsupported_version detail: 21.0.12.1; 64-bit; runtime only; D:\REA逆向\tools\jdk-21.0.12.1+1; accepted a 64-bit full JDK 21 or newer fix: Update JAVA_HOME to the root of a 64-bit full JDK 21 or newer installation. ``` The identical JDK, moved to an ASCII path, passes: ``` [OK] java detail: 21.0.12.1; 64-bit; JDK; D:\tools\jdk-21.0.12.1+1; accepted a 64-bit full JDK 21 or newer ``` In both cases every other Ghidra check passes (`configuration`, `platform`, `architecture`, `installation`, `version`, `headless`, `native_decompiler`, `native_authority`), and `rea analyze` works normally once the provider is admitted. ## Reproduction 1. Extract a full JDK 21 to a directory whose path contains non-ASCII characters, for example `D:\REA逆向\tools\jdk-21.0.12.1+1`. Extract Ghidra 12.1.4 to any path. 2. Set `JAVA_HOME` to the JDK path and `GHIDRA_INSTALL_DIR` to the Ghidra path. 3. Run `rea doctor --json`. The Ghidra candidate is reported unavailable, and the `java` check is `ok: false` with detail `"runtime only"` (see above). 4. Move the same JDK directory to an ASCII path (`D:\tools\jdk-21.0.12.1+1`), point `JAVA_HOME` at it, and rerun `rea doctor --json`. The `java` check is now `ok: true`, detail `"JDK"`, and the Ghidra candidate status becomes `available`. Reduced reproduction of the underlying probe (no REA involved), run on a Chinese-locale Windows host: ```js const { spawnSync } = require('child_process'); const java = process.env.JAVA_HOME + '/bin/java.exe'; const grab = (out) => (/^\s*java\.home\s*=\s*(.+?)\s*$/mu.exec(out)?.[1]) ?? null; const run = (extra) => { const r = spawnSync(java, [...extra, '-XX:-UsePerfData', '-XshowSettings:properties', '-version'], { encoding: 'utf8', windowsHide: true, maxBuffer: Infinity }); return grab(`${r.stdout ?? ''}\n${r.stderr ?? ''}`); }; console.log('default:', JSON.stringify(run([]))); console.log('utf8 :', JSON.stringify(run(['-Dstdout.encoding=UTF-8', '-Dstderr.encoding=UTF-8']))); ``` Output: ``` default: "D:\\REA\uFFFD\uFFFD\\tools\\jdk-21.0.12.1+1" utf8 : "D:\\REA\u9006\u5411\\tools\\jdk-21.0.12.1+1" ``` `fs.accessSync(<java.home> + '/bin/javac.exe', fs.constants.X_OK)` throws `ENOENT` for the first and succeeds for the second. ## Expected behavior A `java.home` containing non-ASCII characters should still be classified as a JDK, exactly as one on an ASCII path is. The probe should either request UTF-8 output from the child JVM explicitly, or decode the child's output using the platform's active codepage instead of assuming UTF-8. `java -Dstdout.encoding=UTF-8 -Dstderr.encoding=UTF-8` demonstrably yields a correctly decoded `java.home` on the same host and JDK, and Java 21 is already the floor for Ghidra 12.1.4, so this does not widen the runtime requirement. ## Impact and scope On any Windows host whose JDK path contains non-ASCII characters, the Ghidra provider cannot be admitted at all: `rea doctor` reports it unavailable and native analysis is refused, even though Ghidra, the JDK, and the native decompiler are installed correctly and every other check passes. This is not limited to one locale — it affects Chinese, Japanese, Korean, Cyrillic, and any other path with non-ASCII characters, which is common on Windows because localized user-profile and install directories frequently contain them (here, the user's own project folder name). Because `ghidraJavaEnvironment` deliberately blanks `_JAVA_OPTIONS`, `JAVA_TOOL_OPTIONS`, `JDK_JAVA_OPTIONS`, and `GHIDRA_JAVA_OPTIONS` for the probe, **there is no environment-variable workaround**: the only fix available to a user is relocating the entire JDK to an ASCII path. That is a surprising requirement, and the resulting `doctor` diagnostic ("runtime only", with remediation "update JAVA_HOME to the root of a 64-bit full JDK") actively points the user away from the real cause — the JDK *is* a full JDK. What is **not** affected: `GHIDRA_INSTALL_DIR` may contain non-ASCII characters, and analysis targets may too — both were verified working end to end (a PE x86-64 target under a non-ASCII path produced correct segments and a matching SHA-256). Evidence integrity, process isolation, target handling, and recovery are unaffected; this is provider admission only. ## Relevant output or evidence `rea doctor --json` fragments for the two configurations are quoted under **Observed behavior**. The full failing check list for the non-ASCII `JAVA_HOME` case: ``` [OK] configuration D:\REA逆向\tools\ghidra_12.1.4_PUBLIC [OK] platform win32 [OK] architecture x64 [OK] installation ...\Ghidra\application.properties [OK] version 12.1.4 [OK] headless ...\support\analyzeHeadless.bat [OK] native_decompiler ...\decompile.exe reports pe x86_64 [FAIL] java ...; runtime only; ...; accepted a 64-bit full JDK 21 or newer ``` With the ASCII JDK path, the same list ends with: ``` [OK] java 21.0.12.1; 64-bit; JDK; D:\tools\jdk-21.0.12.1+1; accepted ... [OK] native_authority Verified Windows native Job Object, private DACL, and reparse-safe handle controls; local NTFS only. ``` ## Typed outcome or recovery expected The `java` provider check should return `ok: true` for a full JDK regardless of the characters in its path. If the path genuinely cannot be used, the check should report a distinct code for the encoding or path condition rather than reusing `unsupported_version`, so the remediation can name the actual problem. ## Analysis or suspected cause **Hypothesis (source-derived reasoning plus a local reproduction, not maintainer-confirmed):** `probeJava` in `src/ghidra/GhidraInstallation.ts` runs ```ts spawnSync(command, ["-XX:-UsePerfData", "-XshowSettings:properties", "-version"], { encoding: "utf8", env: environment, timeout: 5_000, ... }) ``` and parses `java.home` out of the captured output before testing `executablePath(join(home, "bin", "javac.exe"))`, where a miss sets `runtime: "jre"` and the `java` check reports `unsupported_version` with the detail text `"runtime only"`. On Windows the JVM writes `-XshowSettings` output using the process's active ANSI codepage (GBK/936 on this host) unless `stdout.encoding` / `stderr.encoding` are set, so non-ASCII characters in `java.home` are already mangled before Node decodes the bytes as UTF-8. The decoded `home` no longer names a real directory, `javac.exe` is not found, and the JDK is misclassified. Requesting UTF-8 output from the child fixes the decode, as shown above. Other providers that shell out to Java on Windows (`src/android/JadxProvider.ts` also manages `JAVA_TOOL_OPTIONS` / `JDK_JAVA_OPTIONS`) may have the same exposure; I have not tested them. ## Additional context - Related but distinct: #1200 and #1222 addressed *relative* installation and Java paths in doctor and setup. This is an output-decoding problem, not a path-shape problem — an absolute, valid, full JDK path fails purely because of the characters in it. - Related: #1698 (keeping JVM warnings out of LaunchSupport output) suggests parsing a child JVM's output is already a recognized fragile area; this is the same surface with an encoding cause. - Suggested regression test: a `probeJava` / doctor fixture whose `java.home` contains a non-ASCII character, asserting the JDK classification and the decoded home path. A unit-level fake of the child output (GBK-encoded bytes for a path with non-ASCII characters, decoded as UTF-8) would pin the behavior without needing a real JDK on Windows CI. - Workaround for other affected users, until this is fixed: keep `JAVA_HOME` on an ASCII-only path.

bsakaguchi

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

closed this issue
added the
area: providers

bug
labels

bsakaguchi commented

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

Author

Owner

@lovecontroing commented on GitHub (Oct 12, 2026):

Adding the two points that were still phrased as inference in the original report. Both are now measured directly, and both are read from REA's own output bytes rather than from a console, so terminal rendering is not involved.

1. REA decodes the path incorrectly; it is not a display artifact

rea doctor --json was captured to a file, then the raw bytes of two check details were inspected. Same run, same non-ASCII path — the only difference is where the path came from:

configuration   (path from the GHIDRA_INSTALL_DIR environment variable)
  ok: true
  detail bytes: D:\\REA\xe9\x80\x86\xe5\x90\x91\\tools\\ghidra_12.1.4_PUBLIC
  contains U+FFFD (ef bf bd): False        <- valid UTF-8; the path is intact

java            (path from the child JVM's java.home)
  ok: false
  detail bytes: 21.0.12.1; 64-bit; runtime only; D:\\REA\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\\tools\\jdk-21.0.12.1+1; accepted a 64-bit full JDK 21 or newer
  contains U+FFFD (ef bf bd): True         <- four replacement characters

Four U+FFFD for a two-character directory name is exactly what a GBK → UTF-8 mis-decode produces: those two characters occupy four bytes in GBK (C4 E6 CF F2), and each byte fails to decode on its own and becomes one replacement character.

This also rules out an alternative explanation I considered — that REA has a validation rule rejecting non-ASCII path shapes. The same path is read correctly when it arrives through the environment; only the subprocess-derived java.home is corrupted.

2. The impact is a hard refusal, not only a `doctor` warning

With JAVA_HOME on the non-ASCII path, rea analyze on a PE x86-64 fixture:

$ rea analyze D:/tools/fixture.exe --format json
exit 1

{"error":"Analysis failed","code":"provider_unavailable","category":"unavailable",
 "message":"The selected analysis provider is unavailable. Review the reported local
            diagnostics or run `rea doctor`, then retry.",
 "retryable":true,
 "details":{"operation":"current_document",
   "selection_reason":"provider_unavailable",
   "requested_provider_id":"auto",
   "candidate_ids":["ghidra","hopper","ida"],
   "rejections":[{"provider_id":"ghidra","code":"unsupported_version",
     "reason":"Update JAVA_HOME to the root of a 64-bit full JDK 21 or newer installation.",
     ...}]}}

So the provider is not merely reported as unavailable: analysis is refused with unsupported_version, and the reason directs the user to the version of their JDK. The JDK here is a full Eclipse Temurin 21.0.12.1 (64-bit, javac present) — the actual problem is the characters in its path. Nothing in the refusal hints at that.

Reproduction for both items

# 1) full JDK 21 at a path containing non-ASCII characters
$env:JAVA_HOME           = 'D:\REA逆向\tools\jdk-21.0.12.1+1'
$env:GHIDRA_INSTALL_DIR  = 'D:\REA逆向\tools\ghidra_12.1.4_PUBLIC'

rea doctor --json > doctor.json     # java check: ok=false, "runtime only", four U+FFFD in detail
rea analyze D:/tools/fixture.exe    # provider_unavailable / unsupported_version

# 2) the same JDK directory, moved to an ASCII path
$env:JAVA_HOME           = 'D:\tools\jdk-21.0.12.1+1'

rea doctor --json                   # java check: ok=true, "JDK"
rea analyze D:/tools/fixture.exe    # succeeds: 9 segments extracted, matching SHA-256

For reference, the ASCII-path success returns provider: rea-workflow with upstream ghidra 12.1.4 and contract rtr-9.1-x64-pe-read-only-v3, and the same fixture analyzed from a non-ASCII target path also succeeds with an identical SHA-256 — so target paths and GHIDRA_INSTALL_DIR are unaffected; only JAVA_HOME is.

Still untested on my side: whether other providers that shell out to Java on Windows share this exposure (src/android/JadxProvider.ts also manages JAVA_TOOL_OPTIONS / JDK_JAVA_OPTIONS around its own child process).

@lovecontroing commented on GitHub (Oct 12, 2026): Adding the two points that were still phrased as inference in the original report. Both are now measured directly, and both are read from REA's own output bytes rather than from a console, so terminal rendering is not involved. ## 1. REA decodes the path incorrectly; it is not a display artifact `rea doctor --json` was captured to a file, then the **raw bytes** of two check details were inspected. Same run, same non-ASCII path — the only difference is where the path came from: ``` configuration (path from the GHIDRA_INSTALL_DIR environment variable) ok: true detail bytes: D:\\REA\xe9\x80\x86\xe5\x90\x91\\tools\\ghidra_12.1.4_PUBLIC contains U+FFFD (ef bf bd): False <- valid UTF-8; the path is intact java (path from the child JVM's java.home) ok: false detail bytes: 21.0.12.1; 64-bit; runtime only; D:\\REA\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\\tools\\jdk-21.0.12.1+1; accepted a 64-bit full JDK 21 or newer contains U+FFFD (ef bf bd): True <- four replacement characters ``` Four `U+FFFD` for a two-character directory name is exactly what a GBK → UTF-8 mis-decode produces: those two characters occupy **four bytes** in GBK (C4 E6 CF F2), and each byte fails to decode on its own and becomes one replacement character. This also rules out an alternative explanation I considered — that REA has a validation rule rejecting non-ASCII path shapes. The same path is read correctly when it arrives through the environment; only the subprocess-derived `java.home` is corrupted. ## 2. The impact is a hard refusal, not only a `doctor` warning With `JAVA_HOME` on the non-ASCII path, `rea analyze` on a PE x86-64 fixture: ``` $ rea analyze D:/tools/fixture.exe --format json exit 1 {"error":"Analysis failed","code":"provider_unavailable","category":"unavailable", "message":"The selected analysis provider is unavailable. Review the reported local diagnostics or run `rea doctor`, then retry.", "retryable":true, "details":{"operation":"current_document", "selection_reason":"provider_unavailable", "requested_provider_id":"auto", "candidate_ids":["ghidra","hopper","ida"], "rejections":[{"provider_id":"ghidra","code":"unsupported_version", "reason":"Update JAVA_HOME to the root of a 64-bit full JDK 21 or newer installation.", ...}]}} ``` So the provider is not merely reported as unavailable: analysis is refused with `unsupported_version`, and the reason directs the user to the **version** of their JDK. The JDK here is a full Eclipse Temurin 21.0.12.1 (64-bit, `javac` present) — the actual problem is the characters in its path. Nothing in the refusal hints at that. ## Reproduction for both items ```powershell # 1) full JDK 21 at a path containing non-ASCII characters $env:JAVA_HOME = 'D:\REA逆向\tools\jdk-21.0.12.1+1' $env:GHIDRA_INSTALL_DIR = 'D:\REA逆向\tools\ghidra_12.1.4_PUBLIC' rea doctor --json > doctor.json # java check: ok=false, "runtime only", four U+FFFD in detail rea analyze D:/tools/fixture.exe # provider_unavailable / unsupported_version # 2) the same JDK directory, moved to an ASCII path $env:JAVA_HOME = 'D:\tools\jdk-21.0.12.1+1' rea doctor --json # java check: ok=true, "JDK" rea analyze D:/tools/fixture.exe # succeeds: 9 segments extracted, matching SHA-256 ``` For reference, the ASCII-path success returns `provider: rea-workflow` with upstream `ghidra 12.1.4` and contract `rtr-9.1-x64-pe-read-only-v3`, and the same fixture analyzed from a non-ASCII *target* path also succeeds with an identical SHA-256 — so target paths and `GHIDRA_INSTALL_DIR` are unaffected; only `JAVA_HOME` is. Still untested on my side: whether other providers that shell out to Java on Windows share this exposure (`src/android/JadxProvider.ts` also manages `JAVA_TOOL_OPTIONS` / `JDK_JAVA_OPTIONS` around its own child process).

bsakaguchi referenced this issue

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

[PR #745] [MERGED] docs: clarify onboarding and align provider guidance #2209

bsakaguchi referenced this issue

2026-11-03 21:43:16 +00:00

[GH-ISSUE #1587] [Feature] Improve task-centered REA onboarding and recovery in Codex skills #535

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

No description provided.

Rows
Columns