[GH-ISSUE #2316] [Bug] capture_process_scenario reports a missing executable or working directory as an execution failure #765

New issue

Closed

opened 2026-10-15 18:28:06 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

Originally created by @kaoru0822-kitauji on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2316

Observed behavior

capture_process_scenario / rea capture-process reports a missing or unusable caller-selected executable or working directory as a process-capture execution failure, not invalid input:

{"executable":"/nonexistent/bin", "working_directory":"/tmp", …}
→ {"code":"process_capture_failed","category":"execution_failure","retryable":false,
   "remediation":{"action":"executable could not be resolved: /nonexistent/bin"},
   "details":{"execution_failure":"executable could not be resolved: /nonexistent/bin"}}

{"executable":"/bin/echo", "working_directory":"/nonexistent", …}
→ {"code":"process_capture_failed","category":"execution_failure", …
   "details":{"execution_failure":"working directory could not be resolved: /nonexistent (ENOENT)"}}

Nothing was executed. The caller's arguments are wrong, and the same tool already reports other argument problems as invalid_request with an issue path. Examples: environment keys containing =, the reserved REA_PROCESS_RUN_ID, and oversized terminal dimensions. Other tools also report a missing caller-selected path as invalid_request naming the field (e.g. inspect_plist). With execution_failure, an agent cannot tell that correcting executable or working_directory will fix the call.

Reproduction

Current main bb2662267, macOS:

echo '{"executable":"/nonexistent/bin","working_directory":"/tmp","timeout_ms":5000}' > s1.json
echo '{"executable":"/bin/echo","working_directory":"/nonexistent","timeout_ms":5000}' > s2.json
rea capture-process s1.json --format json
rea capture-process s2.json --format json

Expected behavior

invalid_request with an issue at ["executable"] or ["working_directory"] carrying the existing detail (the resolution failure, the checked candidates, the OS code). The same applies to a working directory that is not a directory, and to an executable that is not a regular executable file.

Cause

resolveProcessScenarioRuntimePaths / resolveExecutable (src/process/capture/ProcessScenarioRuntimeValidation.ts) throw ProcessCaptureError for these caller-selection failures. ProcessHarness then returns any non-ProcessCaptureError wrapped as ProcessCaptureError, which projects to process_capture_failed / execution_failure.

Originally created by @kaoru0822-kitauji on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2316 ### Observed behavior `capture_process_scenario` / `rea capture-process` reports a missing or unusable caller-selected executable or working directory as a process-capture execution failure, not invalid input: ```text {"executable":"/nonexistent/bin", "working_directory":"/tmp", …} → {"code":"process_capture_failed","category":"execution_failure","retryable":false, "remediation":{"action":"executable could not be resolved: /nonexistent/bin"}, "details":{"execution_failure":"executable could not be resolved: /nonexistent/bin"}} {"executable":"/bin/echo", "working_directory":"/nonexistent", …} → {"code":"process_capture_failed","category":"execution_failure", … "details":{"execution_failure":"working directory could not be resolved: /nonexistent (ENOENT)"}} ``` Nothing was executed. The caller's arguments are wrong, and the same tool already reports other argument problems as `invalid_request` with an issue path. Examples: `environment` keys containing `=`, the reserved `REA_PROCESS_RUN_ID`, and oversized `terminal` dimensions. Other tools also report a missing caller-selected path as `invalid_request` naming the field (e.g. `inspect_plist`). With `execution_failure`, an agent cannot tell that correcting `executable` or `working_directory` will fix the call. ### Reproduction Current main bb2662267, macOS: ```sh echo '{"executable":"/nonexistent/bin","working_directory":"/tmp","timeout_ms":5000}' > s1.json echo '{"executable":"/bin/echo","working_directory":"/nonexistent","timeout_ms":5000}' > s2.json rea capture-process s1.json --format json rea capture-process s2.json --format json ``` ### Expected behavior `invalid_request` with an issue at `["executable"]` or `["working_directory"]` carrying the existing detail (the resolution failure, the checked candidates, the OS code). The same applies to a working directory that is not a directory, and to an executable that is not a regular executable file. ### Cause `resolveProcessScenarioRuntimePaths` / `resolveExecutable` (`src/process/capture/ProcessScenarioRuntimeValidation.ts`) throw `ProcessCaptureError` for these caller-selection failures. `ProcessHarness` then returns any non-`ProcessCaptureError` wrapped as `ProcessCaptureError`, which projects to `process_capture_failed` / `execution_failure`.

bsakaguchi

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

closed this issue
added the
bug
label

bsakaguchi commented

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

Author

Owner

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

I filed this, but I'm holding back the fix because the intended classification is unclear.

tests/acceptance/tools/localToolContracts.test.ts > rejects malformed process choices through CLI and MCP before launching the command (since 44fd18305) asserts both sides of the line I was going to move:

Malformed requests are invalid_request: NUL bytes in executable, arguments, working_directory or environment values, keys containing =, REA_PROCESS_RUN_ID, out-of-order events.
A well-formed but nonexistent executable is explicitly process_capture_failed, with the path in message and in details.execution_failure.

So the current behavior looks deliberate: a request that is valid in itself but names something absent on this host is treated as a runtime resolution failure. Other tools draw the line the other way, though. inspect_plist and the merged Frida script-file preflight (#2211) report a missing caller-selected path as invalid_request with an issue at the field. An agent receiving process_capture_failed / execution_failure with retryable: false cannot tell that changing executable or working_directory would succeed.

A small change is ready if you want the input-error classification. resolveProcessScenarioRuntimePaths / resolveExecutable would raise AnalysisInputError with an ["executable"] or ["working_directory"] issue carrying the existing detail, and ProcessHarness would return it without rewrapping. That flips the assertion above, so I won't open a PR unless that's the classification you want. If the current split is intended, this issue can be closed.

@kaoru0822-kitauji commented on GitHub (Oct 12, 2026): I filed this, but I'm holding back the fix because the intended classification is unclear. `tests/acceptance/tools/localToolContracts.test.ts > rejects malformed process choices through CLI and MCP before launching the command` (since 44fd18305) asserts both sides of the line I was going to move: - Malformed requests are `invalid_request`: NUL bytes in `executable`, `arguments`, `working_directory` or environment values, keys containing `=`, `REA_PROCESS_RUN_ID`, out-of-order events. - A well-formed but nonexistent `executable` is explicitly `process_capture_failed`, with the path in `message` and in `details.execution_failure`. So the current behavior looks deliberate: a request that is valid in itself but names something absent on this host is treated as a runtime resolution failure. Other tools draw the line the other way, though. `inspect_plist` and the merged Frida script-file preflight (#2211) report a missing caller-selected path as `invalid_request` with an issue at the field. An agent receiving `process_capture_failed` / `execution_failure` with `retryable: false` cannot tell that changing `executable` or `working_directory` would succeed. A small change is ready if you want the input-error classification. `resolveProcessScenarioRuntimePaths` / `resolveExecutable` would raise `AnalysisInputError` with an `["executable"]` or `["working_directory"]` issue carrying the existing detail, and `ProcessHarness` would return it without rewrapping. That flips the assertion above, so I won't open a PR unless that's the classification you want. If the current split is intended, this issue can be closed.

bsakaguchi referenced this issue

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

[PR #767] [CLOSED] fix(native): preserve app bundle executable filename whitespace #2228

bsakaguchi referenced this issue

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

[PR #857] [MERGED] fix(target): decode app Info.plist executables with an XML parser #2294

bsakaguchi referenced this issue

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

[GH-ISSUE #7556] [Bug] inspect-macho fails when the executable filename ends in parentheses #4495

bsakaguchi referenced this issue

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

[GH-ISSUE #7575] [Bug] Valid backslash-named app executables fail bundle admission on macOS #4513