morluto/rea

Fork 0

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

[GH-ISSUE #7548] [Bug] Setup directs callers to repair a client file when the invalid setting comes only from the launching shell #4488

New issue

Closed

opened 2026-10-31 00:50:13 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:50:13 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 27, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7548

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

Starting setup with REA_ASAR_MAX_HEADER_BYTES=0 in its process environment causes this command to exit 1:

node scripts/rea.mjs setup --client claude_code --yes --format json

The result is status: "needs_human" with empty planned and applied actions. Its remediation says that the Claude Code configuration has an invalid REA server environment and must be repaired. In the fresh-home reproduction, that configuration file did not exist. Removing only the launch override allowed the same setup command to create the registration and return ready.

I also observed this with an existing valid registration whose environment contained only CALLER_KEY=keep: supplying REA_BRIDGE_MAX_REQUEST_BYTES=1 only to the setup process caused remediation to blame the existing file. Its bytes remained unchanged, it contained no bridge-budget setting, and no backup was created by the rejected run.

Reproduction

Use the source revision below with Node.js v24.22.1 and its locked dependencies and built runtime. From the checkout root, create a disposable home and run setup with an otherwise empty environment:

WORK=$(mktemp -d)
mkdir -p "$WORK/config" "$WORK/data" "$WORK/cache" "$WORK/state"
run_setup() {
  env -i PATH="$PATH" HOME="$WORK" \
    XDG_CONFIG_HOME="$WORK/config" XDG_DATA_HOME="$WORK/data" \
    XDG_CACHE_HOME="$WORK/cache" XDG_STATE_HOME="$WORK/state" \
    "$@" node scripts/rea.mjs setup --client claude_code --yes --format json
}
run_setup REA_ASAR_MAX_HEADER_BYTES=0 > "$WORK/invalid.json"
echo "$?"
test -e "$WORK/.claude.json"
echo "$?"

Both exit-code checks print 1. The JSON names $WORK/.claude.json as the invalid environment's location despite its absence.

Remove only the launch override and rerun against the same home:
```
run_setup > "$WORK/recovered.json"
echo "$?"
test -e "$WORK/.claude.json"
echo "$?"
```
Both checks print 0. The JSON reports ready and applied actions including configured_claude_code and installed_skill. This control writes only to the disposable home.

The fresh-home failure and recovery each reproduced twice. The existing-registration variant reproduced once. All executions isolated HOME and the four XDG roots; no personal registration was used.

Expected behavior

Setup should reject the invalid launch value before writing, then identify the launch environment or proposed registration override as the repair location. It should preserve the setting name and constraint without asserting that an absent or valid destination file supplied the value.

The installation guide promises validation before writes for retained registration settings and tells callers to repair those settings in their client configuration. The limits-and-recovery design separately distinguishes the launch environment from the registration and requires recovery text to identify a known source and where to change the setting. A value supplied only by the shell needs shell-level recovery guidance.

Impact and scope

The affected caller cannot complete setup until the launch value is corrected. Following the returned instruction to repair the named file cannot remove a value supplied by the shell, and that file may not yet exist. Removing the invalid launch selection restored setup in the executed controls. Invalid-value rejection and preservation of the existing file worked as expected.

Observed scope is Claude Code setup on macOS with two explicit launch settings. Other clients and platforms were not exercised. No target analysis or provider session was involved.

REA version

Exact output of node scripts/rea.mjs --version:

6.8.0

Source baseline: 65f1c447344a423fa2785847dbcea1e9a9e2454a.

Runtime and platform

Node.js v24.22.1; Darwin 27.0.0; arm64. Verification used the checkout's existing built runtime and locked dependencies. The published npm package was not exercised.

Target and artifact context

No analysis target. Inputs were disposable client configuration directories and explicit setup-process environment overrides.

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

The fresh-home command above returned this remediation, with its disposable directory replaced by <home>:

Claude Code: Configuration <home>/.claude.json has an invalid REA server environment: REA_ASAR_MAX_HEADER_BYTES: REA_ASAR_MAX_HEADER_BYTES must be a positive decimal integer of at most 268435456 bytes (256 MiB); the default is 16777216 bytes (16 MiB).. Repair it before rerunning setup.

At that point the file-existence check failed, plannedActions and appliedActions were empty, and stderr was empty. Removing the launch setting produced ready, created that file, and applied configured_claude_code and installed_skill.

Baseline locators:

docs/installation.md:94-113 describes preservation and validation of registration environment values.
docs/design/limits-and-recovery.md:232-237 distinguishes launch-environment and registration repair; lines 269-284 require source and repair-location guidance.
src/application/SetupRegistrationEnvironment.ts:4-95 selects both reproduced environment settings for copying, and src/application/SetupHost.ts:228-238 adds those selections to the proposed registration environment.
src/application/ClientConfigurationFiles.ts:98-124 validates file fragments and the effective environment with proposed overrides. Its error constructor at lines 22-29 always attributes a rejected environment to a configuration path, including when no document exists.
src/application/DoctorDiagnostics.ts:244-260 already gives shell-or-registration guidance for launch configuration failures.

Analysis or suspected cause

Source-derived explanation: setup validates a merged environment containing existing registration values and proposed overrides from its own launch environment. The error projection retains a destination path but does not distinguish which layer supplied the rejected setting. The rejection is correct; the projected recovery location is wrong.

A restoration check should keep invalid values rejected without writes, while identifying the launching environment when it supplied the bad value. Invalid values genuinely stored in the client file should continue to name that file.

Additional context

Closed #2665 and its superseded PR #2769 concern invalid settings already stored in registrations being reported as aligned. This report concerns incorrect recovery attribution after successful rejection of a proposed launch override. As a distinction control, I placed malformed HOPPER_LOADER_ARGS_JSON in an existing registration with no bad launch override: setup correctly returned needs_human, named the stored setting and file, preserved its bytes, and created no backup. This is not a claim that the old acceptance defect regressed.

Originally created by @coygeek on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7548 ### 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 Starting setup with `REA_ASAR_MAX_HEADER_BYTES=0` in its process environment causes this command to exit 1: ```sh node scripts/rea.mjs setup --client claude_code --yes --format json ``` The result is `status: "needs_human"` with empty planned and applied actions. Its remediation says that the Claude Code configuration has an invalid REA server environment and must be repaired. In the fresh-home reproduction, that configuration file did not exist. Removing only the launch override allowed the same setup command to create the registration and return `ready`. I also observed this with an existing valid registration whose environment contained only `CALLER_KEY=keep`: supplying `REA_BRIDGE_MAX_REQUEST_BYTES=1` only to the setup process caused remediation to blame the existing file. Its bytes remained unchanged, it contained no bridge-budget setting, and no backup was created by the rejected run. ### Reproduction 1. Use the source revision below with Node.js v24.22.1 and its locked dependencies and built runtime. From the checkout root, create a disposable home and run setup with an otherwise empty environment: ```sh WORK=$(mktemp -d) mkdir -p "$WORK/config" "$WORK/data" "$WORK/cache" "$WORK/state" run_setup() { env -i PATH="$PATH" HOME="$WORK" \ XDG_CONFIG_HOME="$WORK/config" XDG_DATA_HOME="$WORK/data" \ XDG_CACHE_HOME="$WORK/cache" XDG_STATE_HOME="$WORK/state" \ "$@" node scripts/rea.mjs setup --client claude_code --yes --format json } run_setup REA_ASAR_MAX_HEADER_BYTES=0 > "$WORK/invalid.json" echo "$?" test -e "$WORK/.claude.json" echo "$?" ``` Both exit-code checks print `1`. The JSON names `$WORK/.claude.json` as the invalid environment's location despite its absence. 2. Remove only the launch override and rerun against the same home: ```sh run_setup > "$WORK/recovered.json" echo "$?" test -e "$WORK/.claude.json" echo "$?" ``` Both checks print `0`. The JSON reports `ready` and applied actions including `configured_claude_code` and `installed_skill`. This control writes only to the disposable home. The fresh-home failure and recovery each reproduced twice. The existing-registration variant reproduced once. All executions isolated HOME and the four XDG roots; no personal registration was used. ### Expected behavior Setup should reject the invalid launch value before writing, then identify the launch environment or proposed registration override as the repair location. It should preserve the setting name and constraint without asserting that an absent or valid destination file supplied the value. The installation guide promises validation before writes for retained registration settings and tells callers to repair those settings in their client configuration. The limits-and-recovery design separately distinguishes the launch environment from the registration and requires recovery text to identify a known source and where to change the setting. A value supplied only by the shell needs shell-level recovery guidance. ### Impact and scope The affected caller cannot complete setup until the launch value is corrected. Following the returned instruction to repair the named file cannot remove a value supplied by the shell, and that file may not yet exist. Removing the invalid launch selection restored setup in the executed controls. Invalid-value rejection and preservation of the existing file worked as expected. Observed scope is Claude Code setup on macOS with two explicit launch settings. Other clients and platforms were not exercised. No target analysis or provider session was involved. ### REA version Exact output of `node scripts/rea.mjs --version`: ```text 6.8.0 ``` Source baseline: `65f1c447344a423fa2785847dbcea1e9a9e2454a`. ### Runtime and platform Node.js v24.22.1; Darwin 27.0.0; arm64. Verification used the checkout's existing built runtime and locked dependencies. The published npm package was not exercised. ### Target and artifact context No analysis target. Inputs were disposable client configuration directories and explicit setup-process environment overrides. ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence The fresh-home command above returned this remediation, with its disposable directory replaced by `<home>`: ```text Claude Code: Configuration <home>/.claude.json has an invalid REA server environment: REA_ASAR_MAX_HEADER_BYTES: REA_ASAR_MAX_HEADER_BYTES must be a positive decimal integer of at most 268435456 bytes (256 MiB); the default is 16777216 bytes (16 MiB).. Repair it before rerunning setup. ``` At that point the file-existence check failed, `plannedActions` and `appliedActions` were empty, and stderr was empty. Removing the launch setting produced `ready`, created that file, and applied `configured_claude_code` and `installed_skill`. Baseline locators: - `docs/installation.md:94-113` describes preservation and validation of registration environment values. - `docs/design/limits-and-recovery.md:232-237` distinguishes launch-environment and registration repair; lines 269-284 require source and repair-location guidance. - `src/application/SetupRegistrationEnvironment.ts:4-95` selects both reproduced environment settings for copying, and `src/application/SetupHost.ts:228-238` adds those selections to the proposed registration environment. - `src/application/ClientConfigurationFiles.ts:98-124` validates file fragments and the effective environment with proposed overrides. Its error constructor at lines 22-29 always attributes a rejected environment to a configuration path, including when no document exists. - `src/application/DoctorDiagnostics.ts:244-260` already gives shell-or-registration guidance for launch configuration failures. ### Analysis or suspected cause Source-derived explanation: setup validates a merged environment containing existing registration values and proposed overrides from its own launch environment. The error projection retains a destination path but does not distinguish which layer supplied the rejected setting. The rejection is correct; the projected recovery location is wrong. A restoration check should keep invalid values rejected without writes, while identifying the launching environment when it supplied the bad value. Invalid values genuinely stored in the client file should continue to name that file. ### Additional context Closed [#2665](https://github.com/morluto/rea/issues/2665) and its superseded [PR #2769](https://github.com/morluto/rea/pull/2769) concern invalid settings already stored in registrations being reported as aligned. This report concerns incorrect recovery attribution after successful rejection of a proposed launch override. As a distinction control, I placed malformed `HOPPER_LOADER_ARGS_JSON` in an existing registration with no bad launch override: setup correctly returned `needs_human`, named the stored setting and file, preserved its bytes, and created no backup. This is not a claim that the old acceptance defect regressed.

bsakaguchi closed this issue

2026-10-31 00:50:13 +00:00

bsakaguchi referenced this issue

2026-10-31 01:13:20 +00:00

[PR #4535] [CLOSED] fix(rizin): disable color by default for one-shot commands #6292

bsakaguchi referenced this issue

2026-10-31 01:13:23 +00:00

[PR #4546] fix(rizin): default debugger sessions to plain output #6297

bsakaguchi referenced this issue

2026-11-01 21:43:29 +00:00

[PR #5269] [MERGED] fix(rizin): default one-shot output to plain presentation #6849