[GH-ISSUE #5103] [Bug] Electron scenario CLI rejects an existing application path after symlink/.. #3139

Closed
opened 2026-10-31 00:37:06 +00:00 by bsakaguchi · 5 comments
Owner

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

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

The registered capture-electron-scenario CLI rewrites application_path: "link/../app" lexically before filesystem admission. With link -> real/inner, the selected directory is real/app, but the CLI looks for sibling app and returns invalid_request with an application_path ENOENT issue. A filesystem read through the original spelling succeeds.

Observed through the production registered command's Cli.serve entry point with inert local fixtures. No Electron executable or provider capture was run.

Reproduction

From the repository root at the source revision below, with locked dependencies installed, run this source-level CLI probe. It creates an isolated home/config and removes its fixture directory afterward. The executable fixture is inert and is never executed: the application-path failure stops admission first. The control calls the shared service with an absent provider to check path admission without launching anything.

WORK=$(mktemp -d)
export WORK
mkdir "$WORK/home" "$WORK/config"
env -i PATH="$PATH" HOME="$WORK/home" XDG_CONFIG_HOME="$WORK/config" WORK="$WORK" node --import tsx --input-type=module <<'JS'
import assert from 'node:assert/strict';
import {mkdir,writeFile,chmod,symlink,readFile,realpath} from 'node:fs/promises';
import {Cli} from 'incur';
import pino from 'pino';
import {registerElectronCommands} from './src/cli/electronCommands.ts';
import {captureElectronScenario} from './src/application/javascript/ElectronActiveObservationService.ts';
import {electronActiveObservationInputSchema} from './src/domain/javascript/electronActiveObservation.ts';
import {resolveCliJsonPaths} from './src/cliJsonInput.ts';
process.chdir(process.env.WORK);
await mkdir('real/inner',{recursive:true});
await mkdir('real/app');
await writeFile('real/app/marker','SELECTED');
await symlink('real/inner','link');
await writeFile('electron','inert fixture; never executed');
await chmod('electron',0o700);
const input={executable_path:'electron',application_path:'link/../app',actions:[]};
assert.equal(await readFile(input.application_path+'/marker','utf8'),'SELECTED');
const cli=Cli.create('repro',{version:'1.0.0'});
registerElectronCommands(cli,pino({level:'silent'}),{});
let output='';
await cli.serve(['capture-electron-scenario',JSON.stringify(input),'--format','json'],{
  stdout:chunk=>{output+=chunk;},exit:()=>{}
});
const result=JSON.parse(output);
assert.equal(result.code,'invalid_request');
const issue=result.details.issues[0];
assert.deepEqual(issue.path,['application_path']);
assert.ok(issue.message.includes(process.cwd()+'/app: ENOENT'));
console.log('selected path reads SELECTED; CLI returns invalid_request for WORK/app (ENOENT)');
const control=electronActiveObservationInputSchema.parse(resolveCliJsonPaths({
  ...input,application_path:await realpath(input.application_path)
},[['executable_path'],['application_path']]));
const checked=await captureElectronScenario(undefined,control);
assert.equal(checked.ok,false);
assert.equal(checked.error._tag,'AnalysisCapabilityUnavailableError');
console.log('filesystem-resolved control passes path admission; stops at absent provider');
process.exitCode=0;
JS
rm -r "$WORK"

The asserted replay and an initial independent probe each reproduced the failure.

Expected behavior

Anchoring an operator-relative JSON path should preserve the directory selected by POSIX filesystem traversal. link/../app should pass the same path-admission stage as its filesystem-resolved spelling. This expectation concerns admission only; it does not assert that the inert fixture is a runnable Electron application.

The caller-selected path contract requires preservation of caller inputs. The path owner documentation explicitly explains why lexical symlink/.. collapse can change file selection. The JSON CLI boundary defines these fields as operator-relative paths resolved before validation.

Impact and scope

A bounded class of existing POSIX application paths fails admission with a misleading missing-path error. This is a behavior defect with a practical workaround: filesystem-resolve the application path before supplying it. That control passed path admission in the probe. Real-world frequency is NOT_ENOUGH_INFO.

Only the Electron application_path failure was executed. Wrong-executable launches, other JSON fields, browser execution, Linux and Windows behavior were not runtime-tested. No file modification by REA or security-boundary crossing was observed.

REA version

Source package version 6.7.0, exact tested SHA 3537e58c1ab29309f06eabf50bc52adba9817a0c. The relevant normalization, schema, CLI callback and Electron admission source files have no differences from stable tag rea-agents-6.7.0 (release SHA 27dc42d10249f0410904a75c0997842eb03b931c). The stable package runtime was not executed.

Runtime and platform

Node.js v26.12.0; macOS 27.0.1; darwin arm64. Source workflow with locked dependencies, including Incur and tsx. No Electron/browser runtime was involved.

Target and artifact context

Owned local directory symlink, marker text file, and inert executable-permission file. No third-party application or external service.

Interface

CLI

Earliest failure stage

Request parsing or validation

Relevant output or evidence

Executed the source probe above. Its assertions passed and printed:

selected path reads SELECTED; CLI returns invalid_request for WORK/app (ENOENT)
filesystem-resolved control passes path admission; stops at absent provider

WORK is the disposable directory prefix, not literal CLI output. The actual registered command returned code: "invalid_request", operation capture_electron_scenario, issue path ["application_path"], reason invalid_value, and ENOENT for the sibling app location. The control returned AnalysisCapabilityUnavailableError after successful path canonicalization, with provider deliberately absent.

The registered CLI callback applies normalization before shared validation and service invocation. The normalizer calls resolve(entry). The service admission resolves the already-altered paths and returns failure before provider capture.

Typed outcome or recovery expected

Do not emit an application-path ENOENT for the missing sibling when the caller selected the existing directory through symlink/.. traversal. Preserve filesystem selection through anchoring, while retaining ordinary relative-path admission and genuine missing-path errors.

Analysis or suspected cause

Source-derived: resolveCliJsonPaths removes the symlink/.. segment using node:path.resolve. Later filesystem canonicalization cannot reconstruct the original selection. This produces the observed admission failure before provider execution.

Additional context

Related #2577 concerns file URLs becoming invented local paths in this JSON boundary; #2272 concerns attribution of genuinely unresolvable fields. Neither covers this existing-path symlink-parent trigger. No duplicate was found in the complete open-and-closed issue snapshot.

Built executable-dispatcher behavior and real-provider outcomes are NOT_ENOUGH_INFO because those entry points were not executed.

Originally created by @coygeek on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5103 ## 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 The registered `capture-electron-scenario` CLI rewrites `application_path: "link/../app"` lexically before filesystem admission. With `link -> real/inner`, the selected directory is `real/app`, but the CLI looks for sibling `app` and returns `invalid_request` with an `application_path` ENOENT issue. A filesystem read through the original spelling succeeds. Observed through the production registered command's `Cli.serve` entry point with inert local fixtures. No Electron executable or provider capture was run. ## Reproduction From the repository root at the source revision below, with locked dependencies installed, run this source-level CLI probe. It creates an isolated home/config and removes its fixture directory afterward. The executable fixture is inert and is never executed: the application-path failure stops admission first. The control calls the shared service with an absent provider to check path admission without launching anything. ```sh WORK=$(mktemp -d) export WORK mkdir "$WORK/home" "$WORK/config" env -i PATH="$PATH" HOME="$WORK/home" XDG_CONFIG_HOME="$WORK/config" WORK="$WORK" node --import tsx --input-type=module <<'JS' import assert from 'node:assert/strict'; import {mkdir,writeFile,chmod,symlink,readFile,realpath} from 'node:fs/promises'; import {Cli} from 'incur'; import pino from 'pino'; import {registerElectronCommands} from './src/cli/electronCommands.ts'; import {captureElectronScenario} from './src/application/javascript/ElectronActiveObservationService.ts'; import {electronActiveObservationInputSchema} from './src/domain/javascript/electronActiveObservation.ts'; import {resolveCliJsonPaths} from './src/cliJsonInput.ts'; process.chdir(process.env.WORK); await mkdir('real/inner',{recursive:true}); await mkdir('real/app'); await writeFile('real/app/marker','SELECTED'); await symlink('real/inner','link'); await writeFile('electron','inert fixture; never executed'); await chmod('electron',0o700); const input={executable_path:'electron',application_path:'link/../app',actions:[]}; assert.equal(await readFile(input.application_path+'/marker','utf8'),'SELECTED'); const cli=Cli.create('repro',{version:'1.0.0'}); registerElectronCommands(cli,pino({level:'silent'}),{}); let output=''; await cli.serve(['capture-electron-scenario',JSON.stringify(input),'--format','json'],{ stdout:chunk=>{output+=chunk;},exit:()=>{} }); const result=JSON.parse(output); assert.equal(result.code,'invalid_request'); const issue=result.details.issues[0]; assert.deepEqual(issue.path,['application_path']); assert.ok(issue.message.includes(process.cwd()+'/app: ENOENT')); console.log('selected path reads SELECTED; CLI returns invalid_request for WORK/app (ENOENT)'); const control=electronActiveObservationInputSchema.parse(resolveCliJsonPaths({ ...input,application_path:await realpath(input.application_path) },[['executable_path'],['application_path']])); const checked=await captureElectronScenario(undefined,control); assert.equal(checked.ok,false); assert.equal(checked.error._tag,'AnalysisCapabilityUnavailableError'); console.log('filesystem-resolved control passes path admission; stops at absent provider'); process.exitCode=0; JS rm -r "$WORK" ``` The asserted replay and an initial independent probe each reproduced the failure. ## Expected behavior Anchoring an operator-relative JSON path should preserve the directory selected by POSIX filesystem traversal. `link/../app` should pass the same path-admission stage as its filesystem-resolved spelling. This expectation concerns admission only; it does not assert that the inert fixture is a runnable Electron application. The [caller-selected path contract](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/AGENTS.md#L13) requires preservation of caller inputs. The [path owner documentation](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/filesystem/callerPath.ts#L3-L11) explicitly explains why lexical symlink/.. collapse can change file selection. The [JSON CLI boundary](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/cliJsonInput.ts#L75-L80) defines these fields as operator-relative paths resolved before validation. ## Impact and scope A bounded class of existing POSIX application paths fails admission with a misleading missing-path error. This is a behavior defect with a practical workaround: filesystem-resolve the application path before supplying it. That control passed path admission in the probe. Real-world frequency is NOT_ENOUGH_INFO. Only the Electron `application_path` failure was executed. Wrong-executable launches, other JSON fields, browser execution, Linux and Windows behavior were not runtime-tested. No file modification by REA or security-boundary crossing was observed. ## REA version Source package version 6.7.0, exact tested SHA `3537e58c1ab29309f06eabf50bc52adba9817a0c`. The relevant normalization, schema, CLI callback and Electron admission source files have no differences from stable tag `rea-agents-6.7.0` (release SHA `27dc42d10249f0410904a75c0997842eb03b931c`). The stable package runtime was not executed. ## Runtime and platform Node.js v26.12.0; macOS 27.0.1; darwin arm64. Source workflow with locked dependencies, including Incur and tsx. No Electron/browser runtime was involved. ## Target and artifact context Owned local directory symlink, marker text file, and inert executable-permission file. No third-party application or external service. ## Interface CLI ## Earliest failure stage Request parsing or validation ## Relevant output or evidence Executed the source probe above. Its assertions passed and printed: ```text selected path reads SELECTED; CLI returns invalid_request for WORK/app (ENOENT) filesystem-resolved control passes path admission; stops at absent provider ``` `WORK` is the disposable directory prefix, not literal CLI output. The actual registered command returned `code: "invalid_request"`, operation `capture_electron_scenario`, issue path `["application_path"]`, reason `invalid_value`, and ENOENT for the sibling `app` location. The control returned `AnalysisCapabilityUnavailableError` after successful path canonicalization, with provider deliberately absent. The [registered CLI callback](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/cli/electronCommands.ts#L104-L128) applies normalization before shared validation and service invocation. The [normalizer](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/cliJsonInput.ts#L101-L108) calls `resolve(entry)`. The [service admission](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/javascript/ElectronActiveObservationService.ts#L74-L95) resolves the already-altered paths and [returns failure before provider capture](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/javascript/ElectronActiveObservationService.ts#L112-L122). ## Typed outcome or recovery expected Do not emit an application-path ENOENT for the missing sibling when the caller selected the existing directory through symlink/.. traversal. Preserve filesystem selection through anchoring, while retaining ordinary relative-path admission and genuine missing-path errors. ## Analysis or suspected cause Source-derived: `resolveCliJsonPaths` removes the symlink/.. segment using `node:path.resolve`. Later filesystem canonicalization cannot reconstruct the original selection. This produces the observed admission failure before provider execution. ## Additional context Related [#2577](https://github.com/morluto/rea/issues/2577) concerns file URLs becoming invented local paths in this JSON boundary; [#2272](https://github.com/morluto/rea/issues/2272) concerns attribution of genuinely unresolvable fields. Neither covers this existing-path symlink-parent trigger. No duplicate was found in the complete open-and-closed issue snapshot. Built executable-dispatcher behavior and real-provider outcomes are NOT_ENOUGH_INFO because those entry points were not executed.
Author
Owner

@XinwangTao commented on GitHub (Oct 19, 2026):

Confirmed — lexical normalization before symlink resolution breaks valid paths: link/../app is collapsed to sibling app before the filesystem sees that link is a symlink, so an existing caller-selected directory gets rejected with ENOENT. That's an ordering bug in admission, not a path-ownership issue.

I'd resolve against the real filesystem first (realpath on the existing segment) and only then normalize for display/use — or at minimum do symlink-aware resolution before the lexical pass — plus a regression test using a symlink + .. combination (as reproduced) so the path contract stays honest for both spellings.

<!-- gh-comment-id:6260219070 --> @XinwangTao commented on GitHub (Oct 19, 2026): Confirmed — lexical normalization before symlink resolution breaks valid paths: link/../app is collapsed to sibling app before the filesystem sees that link is a symlink, so an existing caller-selected directory gets rejected with ENOENT. That's an ordering bug in admission, not a path-ownership issue. I'd resolve against the real filesystem first (realpath on the existing segment) and only then normalize for display/use — or at minimum do symlink-aware resolution before the lexical pass — plus a regression test using a symlink + .. combination (as reproduced) so the path contract stays honest for both spellings.
Author
Owner

@dxqlovestudy commented on GitHub (Oct 19, 2026):

Taking this one.

Plan: route caller-selected CLI JSON paths through the existing absoluteCallerPath owner in src/filesystem/callerPath.ts instead of path.resolve() in src/cliJsonInput.ts. That helper already keeps every .. for the POSIX filesystem to resolve after the preceding symlink (and resolves lexically on Win32, where that is exact), so link/../app keeps naming real/app while blank/URL handling and non-existent-path behavior stay unchanged.

Validation: a regression test will build link -> real/inner under a temp root and assert the CLI-normalized application_path still names the existing real/app, with the previous lexical result (<root>/app, missing) as the control; existing src/cliJsonPaths.test.ts cases must stay green, plus npm run check:fast.

<!-- gh-comment-id:6261916175 --> @dxqlovestudy commented on GitHub (Oct 19, 2026): Taking this one. Plan: route caller-selected CLI JSON paths through the existing `absoluteCallerPath` owner in `src/filesystem/callerPath.ts` instead of `path.resolve()` in `src/cliJsonInput.ts`. That helper already keeps every `..` for the POSIX filesystem to resolve after the preceding symlink (and resolves lexically on Win32, where that is exact), so `link/../app` keeps naming `real/app` while blank/URL handling and non-existent-path behavior stay unchanged. Validation: a regression test will build `link -> real/inner` under a temp root and assert the CLI-normalized `application_path` still names the existing `real/app`, with the previous lexical result (`<root>/app`, missing) as the control; existing `src/cliJsonPaths.test.ts` cases must stay green, plus `npm run check:fast`.
Author
Owner

@XinwangTao commented on GitHub (Oct 19, 2026):

Thanks @dxqlovestudy — routing through absoluteCallerPath matches the realpath-first direction: it keeps the .. for the POSIX filesystem to resolve after the symlink, while lexical collapse stays exact on Win32. One boundary worth asserting in the regression test: a genuinely missing path should still surface the original ENOENT (the #2272 attribution case), so the fix restores symlink-parent selection without blurring real missing-path errors.

<!-- gh-comment-id:6262672883 --> @XinwangTao commented on GitHub (Oct 19, 2026): Thanks @dxqlovestudy — routing through absoluteCallerPath matches the realpath-first direction: it keeps the `..` for the POSIX filesystem to resolve after the symlink, while lexical collapse stays exact on Win32. One boundary worth asserting in the regression test: a genuinely missing path should still surface the original ENOENT (the #2272 attribution case), so the fix restores symlink-parent selection without blurring real missing-path errors.
Author
Owner

@xu91102 commented on GitHub (Oct 20, 2026):

I reproduced this through the actual built public CLI at main 833136507dd79d959340b09862a53af344e4f1b3, using the pinned Node24.18.0 on macOS arm64.

Nine isolated controls completed with unchanged authored input bytes:

  • Four existing caller-selected paths are rejected as invalid_request/ENOENT: relative and absolute application_path containing link/../app, relative executable_path containing a symlink-parent traversal, and the same traversal in application_root. The OS filesystem realpath resolves every selected input successfully; the diagnostic instead names the lexically collapsed sibling. These failures occur before the selected executable is invoked.
  • Canonical and ordinary-relative controls pass path admission and invoke only my finite authored argv-recording executable. It intentionally exits77, producing an expected later execution_failure; this is not a successful Electron capture or real Electron qualification.
  • Genuinely missing, file-URL and blank application-path controls correctly refuse before launch.

The producing resolveCliJsonPaths boundary calls lexical path.resolve before the service's filesystem canonicalization, so the latter cannot recover the original selection. The existing absoluteCallerPath owner already preserves POSIX symlink/parent traversal and retains native Windows normalization. I am preparing a small correction at that shared CLI JSON boundary, without changing the Electron provider or MCP path contract.

Related actual production diffs for #5029/#1273/#1412/#1472 were read: they concern JSON source-selection input, regular-file admission, decoding and capacity; they do not fix this named-path anchoring. Public CLI path admission and the finite launcher controls above are the observed scope. At that initial reproduction stage, full Electron application/browser capture, Windows/Linux hosts, installed-package and performance coverage had not yet been run.

Update: the three-file correction is now normally committed and pushed to my fork as d4ac83892, based on the tested main833 baseline. The shared adapter uses the existing caller-path owner; no provider, schema or MCP absolute-path change. There is currently no upstream PR or upstream CI for this fix.

Independent Standards and Spec review both passed on identical frozen inputs. Eleven affected test files passed98 tests across separate runs; fresh README5 gives12 distinct files103PASS/0skip, without adding overlapping/RED counts. Code checks (0 errors/1795 warnings), docs,1704-file discovery, actual installed-package CLI/MCP209tools/6prompts, exact-release update and awaited cleanup passed. The four original wrong rejections are corrected on the same compiled and installed inputs, with ordinary positives and missing/URL/blank refusals retained. The finite launcher still deliberately exits77; no successful Electron capture is claimed.

The other shared consumer, nested browser executable paths, was checked with20 existing regressions and30 additional public CLI controls across baseline/fixed compiled/installed entries. Controlled sessions and finite executables verify handoff/Evidence/error/cleanup behavior; the browser provider's existing second lexical resolve is unchanged. A separate native Chrome baseline probe completed one absolute-path scenario, then failed for a nested-relative executable with cleanup_incomplete; both raw outcomes were retained and no owned Chrome/profile remained at readback. These two baseline calls are excluded from the103PASS and do not qualify the fixed source. Fixed-source full native Electron/browser/CDP/agent/model, Windows/Linux hosts and performance remain unverified.

Later-main note: main f93a0335a8c1a60bbf6debdca16675ba303e4422 subsequently added a third resolveCliJsonPaths consumer for evidence-file source.path in inspect-analysis-view. I read that actual production diff; it adds the consumer and leaves the shared normalizer unchanged. The source/package/103PASS and two-consumer preservation evidence above remain bound to833. No later-main or new-consumer runtime pass is claimed; that preservation needs fresh integration checks before an upstream PR.

Main coverage update (2026-10-21)

Main commit 1bfa60ac2 now fixes this report's core issue. I read the actual change and confirmed it is included in captured main d0067ba34a39ea47dd7e11bb2e6169bc0938cc3f. My unsubmitted fork preparation is now on read-only HOLD to avoid a duplicate PR. I have not run the main fix through the complete original workflow, and do not transfer the fork's validation results to main or claim source adoption or author credit. No upstream PR was created from my branch.

<!-- gh-comment-id:6281014542 --> @xu91102 commented on GitHub (Oct 20, 2026): I reproduced this through the actual built public CLI at main `833136507dd79d959340b09862a53af344e4f1b3`, using the pinned Node24.18.0 on macOS arm64. Nine isolated controls completed with unchanged authored input bytes: - Four existing caller-selected paths are rejected as `invalid_request`/ENOENT: relative and absolute `application_path` containing `link/../app`, relative `executable_path` containing a symlink-parent traversal, and the same traversal in `application_root`. The OS filesystem `realpath` resolves every selected input successfully; the diagnostic instead names the lexically collapsed sibling. These failures occur before the selected executable is invoked. - Canonical and ordinary-relative controls pass path admission and invoke only my finite authored argv-recording executable. It intentionally exits77, producing an expected later `execution_failure`; this is not a successful Electron capture or real Electron qualification. - Genuinely missing, file-URL and blank application-path controls correctly refuse before launch. The producing `resolveCliJsonPaths` boundary calls lexical `path.resolve` before the service's filesystem canonicalization, so the latter cannot recover the original selection. The existing `absoluteCallerPath` owner already preserves POSIX symlink/parent traversal and retains native Windows normalization. I am preparing a small correction at that shared CLI JSON boundary, without changing the Electron provider or MCP path contract. Related actual production diffs for #5029/#1273/#1412/#1472 were read: they concern JSON source-selection input, regular-file admission, decoding and capacity; they do not fix this named-path anchoring. Public CLI path admission and the finite launcher controls above are the observed scope. At that initial reproduction stage, full Electron application/browser capture, Windows/Linux hosts, installed-package and performance coverage had not yet been run. Update: the three-file correction is now normally committed and pushed to my fork as [d4ac83892](https://github.com/xu91102/rea/commit/d4ac83892a45d980894ccc504afb639896b9c8f3), based on the tested main833 baseline. The shared adapter uses the existing caller-path owner; no provider, schema or MCP absolute-path change. There is currently no upstream PR or upstream CI for this fix. Independent Standards and Spec review both passed on identical frozen inputs. Eleven affected test files passed98 tests across separate runs; fresh README5 gives12 distinct files103PASS/0skip, without adding overlapping/RED counts. Code checks (0 errors/1795 warnings), docs,1704-file discovery, actual installed-package CLI/MCP209tools/6prompts, exact-release update and awaited cleanup passed. The four original wrong rejections are corrected on the same compiled and installed inputs, with ordinary positives and missing/URL/blank refusals retained. The finite launcher still deliberately exits77; no successful Electron capture is claimed. The other shared consumer, nested browser executable paths, was checked with20 existing regressions and30 additional public CLI controls across baseline/fixed compiled/installed entries. Controlled sessions and finite executables verify handoff/Evidence/error/cleanup behavior; the browser provider's existing second lexical resolve is unchanged. A separate native Chrome baseline probe completed one absolute-path scenario, then failed for a nested-relative executable with cleanup_incomplete; both raw outcomes were retained and no owned Chrome/profile remained at readback. These two baseline calls are excluded from the103PASS and do not qualify the fixed source. Fixed-source full native Electron/browser/CDP/agent/model, Windows/Linux hosts and performance remain unverified. Later-main note: main `f93a0335a8c1a60bbf6debdca16675ba303e4422` subsequently added a third `resolveCliJsonPaths` consumer for evidence-file `source.path` in `inspect-analysis-view`. I read that actual production diff; it adds the consumer and leaves the shared normalizer unchanged. The source/package/103PASS and two-consumer preservation evidence above remain bound to833. No later-main or new-consumer runtime pass is claimed; that preservation needs fresh integration checks before an upstream PR. ### Main coverage update (2026-10-21) Main commit [1bfa60ac2](https://github.com/morluto/rea/commit/1bfa60ac20e1a344bcf3132c08d15b6860b05c61) now fixes this report's core issue. I read the actual change and confirmed it is included in captured main `d0067ba34a39ea47dd7e11bb2e6169bc0938cc3f`. My unsubmitted fork preparation is now on read-only HOLD to avoid a duplicate PR. I have not run the main fix through the complete original workflow, and do not transfer the fork's validation results to main or claim source adoption or author credit. No upstream PR was created from my branch.
Author
Owner

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

Closing as fixed on main by github.com/morluto/rea@1bfa60ac20, retained at current main 67a6477f01.

The shared CLI JSON input owner now uses absoluteCallerPath rather than lexical path.resolve, preserving POSIX symlink/parent traversal. Registered Electron, browser and analysis-view boundaries have regression coverage, including relative/absolute selection and invalid/missing suffix refusals; an acceptance test checks the selected Evidence identity through the built CLI. This also matches the current-main coverage update already posted in this issue.

This audit verified the committed producer and regression coverage by source inspection. It did not rerun the runtime reproduction or establish additional real-provider/platform coverage.

<!-- gh-comment-id:6324196438 --> @morluto commented on GitHub (Oct 21, 2026): Closing as fixed on main by https://github.com/morluto/rea/commit/1bfa60ac20e1a344bcf3132c08d15b6860b05c61, retained at current main 67a6477f011ae358fc333e5a6e26c86d932654ed. The shared CLI JSON input owner now uses absoluteCallerPath rather than lexical path.resolve, preserving POSIX symlink/parent traversal. Registered Electron, browser and analysis-view boundaries have regression coverage, including relative/absolute selection and invalid/missing suffix refusals; an acceptance test checks the selected Evidence identity through the built CLI. This also matches the current-main coverage update already posted in this issue. This audit verified the committed producer and regression coverage by source inspection. It did not rerun the runtime reproduction or establish additional real-provider/platform coverage.
Sign in to join this conversation.
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#3139
No description provided.