morluto/rea
1
0
Fork 0
mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00
Code Issues 1.3k Projects Packages Wiki Activity

[GH-ISSUE #2300] [Feature] Show one function's pseudocode from several decompiler providers in one call #764

New issue
Open
opened 2026-10-15 18:28:06 +00:00 by bsakaguchi · 3 comments
bsakaguchi commented 2026-10-15 18:28:06 +00:00
Owner
Copy link

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

Before submitting

  • I searched the open and closed issues and pull requests for a related proposal.
  • I understand the contribution scope must be reviewed before integration; open questions are welcome here.
  • This request does not include credentials, private samples, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

REA integrates three deep providers (Hopper, Ghidra, IDA), but a session binds exactly one. open_binary.provider_id "selects one deep provider ... the binding remains stable until close or an explicit switch" (src/contracts/sessionToolContracts.ts), and BinarySession owns a single active target whose switch "tears down the active provider client" (src/application/binary/BinarySession.ts). procedure_pseudo_code, batch_decompile and analyze_function take no provider argument, and the CLI's --provider accepts one provider ID or auto.

compare_functions accepts analyze_function Evidence from two different providers, but then returns the pseudocode and assembly dimensions as unknown with null digests and only character counts ("Exact text comparison requires one provider identity."), so the texts are not in its result (src/domain/functionComparisonDimensions.ts). It has no CLI command.

To read one function's pseudocode from two providers today, an MCP user opens with provider A, runs analyze_function, re-opens with provider B (which discards the binding to A and imports the target again), runs analyze_function, and lines the dossiers up by hand. A CLI user runs rea decompile PATH PROC --provider A --json and again with --provider B. Nothing checks that both providers resolved the same function, and nothing keeps the outputs together with their provenance.

Use cases

  • Check a doubtful decompilation (switch recovery, types, no-return cuts, calling convention) in a second engine before relying on it.
  • Let an agent cite which provider produced which reading when the providers disagree, instead of silently trusting one.
  • Keep the analyst's current provider binding while taking a quick second opinion.

Desired outcome and success criteria

One CLI command and one MCP call take a target, one procedure selector and two or more provider IDs, and return one entry per provider in request order. Each entry has the provider's identity, version and analysis profile; the entry address and name it resolved; its pseudocode text exactly as produced, or null; its own limitations; and ok or a typed error. The result never ranks the texts or claims they are equivalent.

Success criteria:

  • On a host with two working providers, one call on a fixture returns pseudocode for the same named function from each, with per-provider provenance.
  • An unconfigured or unsupported provider yields an entry with the existing provider-selection rejection code (not_configured, target_format_unsupported and so on), and the other providers' output is still returned. Timeouts and failures report their original reason and do not discard the other entries.
  • When REA cannot show that the resolved entries are the same function (provider addresses are provider-normalized and image bases can differ), function agreement is reported as unknown or mismatched, never assumed.
  • In MCP, binary_session shows the same target, provider binding and run after the call. No provider process started for the comparison survives completion or cancellation.
  • Per-provider Evidence plus derived combined Evidence that cites the target SHA-256 and links each entry; it round-trips through export_evidence_bundle and import_evidence_bundle.
  • Catalog, CLI help and docs/native-investigation.md document the operation. Adapter tests cover success, partial failure, unavailable providers and cancellation, and one real-toolchain run with two real providers covers the success path.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Local native binaries that REA's existing deep providers already accept. Each requested provider runs as a local subprocess or attached engine, as open_binary already does, and reads the target statically; nothing executes the target. This adds no new provider and uses no network service. Running several providers in one call raises resource use and adds provider lifecycles, so the bounds on concurrency, deadlines and cleanup need maintainer review.

Verification available so far

Idea only; I need help defining checks

Verification details (optional)

Claims above were checked against REA main source and docs at aeee5074d1 (6.4.0). No prototype was run against real providers.

Alternatives considered

  • Extend compare_functions to return both texts when providers differ. This is small, but it still needs two provider runs and a switch or a second session first, so it does not give a one-call result. It could complement this feature.
  • Let one session bind several providers and add provider_id to procedure_pseudo_code and batch_decompile. This is more flexible but breaks the documented one-immutable-provider session contract and is much larger.
  • Document the existing switch-and-reopen sequence as the supported workflow. This needs no code but discards the active binding, repeats the import, and leaves alignment and same-function checks to the agent.

Possible direction

A provider-neutral comparison operation that opens short-lived, comparison-only provider sessions for the requested providers, separate from the bound session. It would reuse the existing pseudocode path and provider-selection rejection codes per provider, and derive one Evidence record linking the per-provider records. Concurrency (sequential or bounded) is open. Non-goals: new providers (Kuna is #1957), semantic or line-level alignment, ranking, and address normalization across builds (#1947, PRs #2124 and #2088).

References

Originally created by @coygeek on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2300 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation REA integrates three deep providers (Hopper, Ghidra, IDA), but a session binds exactly one. `open_binary.provider_id` "selects one deep provider ... the binding remains stable until close or an explicit switch" ([src/contracts/sessionToolContracts.ts](https://github.com/morluto/rea/blob/main/src/contracts/sessionToolContracts.ts)), and `BinarySession` owns a single active target whose switch "tears down the active provider client" ([src/application/binary/BinarySession.ts](https://github.com/morluto/rea/blob/main/src/application/binary/BinarySession.ts)). `procedure_pseudo_code`, `batch_decompile` and `analyze_function` take no provider argument, and the CLI's `--provider` accepts one provider ID or `auto`. `compare_functions` accepts `analyze_function` Evidence from two different providers, but then returns the `pseudocode` and `assembly` dimensions as `unknown` with null digests and only character counts ("Exact text comparison requires one provider identity."), so the texts are not in its result ([src/domain/functionComparisonDimensions.ts](https://github.com/morluto/rea/blob/main/src/domain/functionComparisonDimensions.ts)). It has no CLI command. To read one function's pseudocode from two providers today, an MCP user opens with provider A, runs `analyze_function`, re-opens with provider B (which discards the binding to A and imports the target again), runs `analyze_function`, and lines the dossiers up by hand. A CLI user runs `rea decompile PATH PROC --provider A --json` and again with `--provider B`. Nothing checks that both providers resolved the same function, and nothing keeps the outputs together with their provenance. ### Use cases - Check a doubtful decompilation (switch recovery, types, no-return cuts, calling convention) in a second engine before relying on it. - Let an agent cite which provider produced which reading when the providers disagree, instead of silently trusting one. - Keep the analyst's current provider binding while taking a quick second opinion. ### Desired outcome and success criteria One CLI command and one MCP call take a target, one procedure selector and two or more provider IDs, and return one entry per provider in request order. Each entry has the provider's identity, version and analysis profile; the entry address and name it resolved; its pseudocode text exactly as produced, or `null`; its own limitations; and `ok` or a typed error. The result never ranks the texts or claims they are equivalent. Success criteria: - On a host with two working providers, one call on a fixture returns pseudocode for the same named function from each, with per-provider provenance. - An unconfigured or unsupported provider yields an entry with the existing provider-selection rejection code (`not_configured`, `target_format_unsupported` and so on), and the other providers' output is still returned. Timeouts and failures report their original reason and do not discard the other entries. - When REA cannot show that the resolved entries are the same function (provider addresses are provider-normalized and image bases can differ), function agreement is reported as `unknown` or mismatched, never assumed. - In MCP, `binary_session` shows the same target, provider binding and run after the call. No provider process started for the comparison survives completion or cancellation. - Per-provider Evidence plus derived combined Evidence that cites the target SHA-256 and links each entry; it round-trips through `export_evidence_bundle` and `import_evidence_bundle`. - Catalog, CLI help and docs/native-investigation.md document the operation. Adapter tests cover success, partial failure, unavailable providers and cancellation, and one real-toolchain run with two real providers covers the success path. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) Local native binaries that REA's existing deep providers already accept. Each requested provider runs as a local subprocess or attached engine, as `open_binary` already does, and reads the target statically; nothing executes the target. This adds no new provider and uses no network service. Running several providers in one call raises resource use and adds provider lifecycles, so the bounds on concurrency, deadlines and cleanup need maintainer review. ### Verification available so far Idea only; I need help defining checks ### Verification details (optional) Claims above were checked against REA `main` source and docs at aeee5074d124414239b6dd440dc79c26bcbd58a4 (6.4.0). No prototype was run against real providers. ### Alternatives considered - Extend `compare_functions` to return both texts when providers differ. This is small, but it still needs two provider runs and a switch or a second session first, so it does not give a one-call result. It could complement this feature. - Let one session bind several providers and add `provider_id` to `procedure_pseudo_code` and `batch_decompile`. This is more flexible but breaks the documented one-immutable-provider session contract and is much larger. - Document the existing switch-and-reopen sequence as the supported workflow. This needs no code but discards the active binding, repeats the import, and leaves alignment and same-function checks to the agent. ### Possible direction A provider-neutral comparison operation that opens short-lived, comparison-only provider sessions for the requested providers, separate from the bound session. It would reuse the existing pseudocode path and provider-selection rejection codes per provider, and derive one Evidence record linking the per-provider records. Concurrency (sequential or bounded) is open. Non-goals: new providers (Kuna is #1957), semantic or line-level alignment, ranking, and address normalization across builds (#1947, PRs #2124 and #2088). ### References - #2258 and gap 6 in the follow-up comment: https://github.com/morluto/rea/issues/2258#issuecomment-6130226337 - Prior art: [decompiler-explorer/decompiler-explorer](https://github.com/decompiler-explorer/decompiler-explorer) (MIT, the code behind dogbolt.org). It records each decompiler's name, version and revision, and stores for each binary and decompiler either an output or an error, plus analysis time. - #26 (closed) evaluated Ghidra, IDA, Binary Ninja, Rizin and LIEF as providers. #37 (closed) asked for "multiple providers in one investigation" and shipped `compare_functions`. #20 (closed) introduced provider-neutral sessions. - Related, distinct: #1947 (address-normalized text for same-provider comparisons), #2222 (`compare_functions` call coverage). - [docs/mcp-contracts.md](https://github.com/morluto/rea/blob/main/docs/mcp-contracts.md) (one immutable provider per deep open), [docs/ghidra-provider.md](https://github.com/morluto/rea/blob/main/docs/ghidra-provider.md) (cross-provider text is never treated as equal or unequal), [docs/tool-design.md](https://github.com/morluto/rea/blob/main/docs/tool-design.md) (when to compose a workflow).
bsakaguchi commented 2026-10-15 18:28:07 +00:00
Author
Owner
Copy link

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

Design & Architectural Boundary Notes

While comparing pseudocode across multiple decompilers (e.g. Hopper vs Ghidra vs IDA) on the same function is highly valuable for reverse engineering fidelity:

  1. Session Boundary Invariant: A BinarySession is designed to own exactly one active provider bridge at a time to prevent port/process contention, excessive RAM overhead (running multiple decompiler engines simultaneously), and state pollution.
  2. Recommended Composition Pattern: Rather than mutating BinarySession into a multi-provider orchestrator, cross-provider comparison is best achieved at the application/workflow or agent layer:
    • Perform independent sessions or query cached Evidence dossiers for the target function produced under each respective provider.
    • Use compare_functions or a dedicated synthesis helper over retained Evidence.
<!-- gh-comment-id:6134280005 --> @matbrgz commented on GitHub (Oct 12, 2026): ### Design & Architectural Boundary Notes While comparing pseudocode across multiple decompilers (e.g. Hopper vs Ghidra vs IDA) on the same function is highly valuable for reverse engineering fidelity: 1. **Session Boundary Invariant:** A `BinarySession` is designed to own exactly one active provider bridge at a time to prevent port/process contention, excessive RAM overhead (running multiple decompiler engines simultaneously), and state pollution. 2. **Recommended Composition Pattern:** Rather than mutating `BinarySession` into a multi-provider orchestrator, cross-provider comparison is best achieved at the application/workflow or agent layer: - Perform independent sessions or query cached `Evidence` dossiers for the target function produced under each respective provider. - Use `compare_functions` or a dedicated synthesis helper over retained Evidence.
bsakaguchi commented 2026-11-01 21:10:53 +00:00
Author
Owner
Copy link

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

Real-provider follow-up on PR #8187 branch, macOS arm64, the same self-built unexecuted Mach-O, Ghidra 12.1.4 and Kuna 1.986:

  1. In one MCP connection, open_binary with Ghidra and analyze_function with summary retained the complete _evaluate dossier. Explicitly opening the same target with Kuna and analyzing _evaluate retained a second dossier; the first reference still resolved after the switch.
  2. compare_functions accepted both retained references. Both providers reported the same name and 0x100000430 in this fixture, but REA correctly returned ambiguous function identity and all eight dimensions unknown: in particular, the providers do not establish a common coordinate commitment or stable Kuna symbol origin, and their text is not a cross-provider invariant.
  3. Exporting the session Evidence bundle preserved both source dossiers and comparison; after close_binary cleared session records, comparison by those IDs failed with actionable evidence_integrity_mismatch. Importing the bundle restored the same comparison Evidence ID. In a fresh MCP server, get_evidence_bundle summary discovered both dossiers and two inspect_analysis_view native-pseudocode pages retrieved each provider's actual text with parent references, coverage and limitations, without reopening a provider.

This refines the original limitation: the current workflow can keep the observations together and recover both texts from retained or bundled Evidence, but it takes a provider switch, two analyses and separate views. A direct composition over already-retained dossiers may therefore be a smaller complementary design than always starting multiple engines; an acquisition workflow would still need separate provider lifecycles, partial failures, cancellation and preservation of the caller's existing binding. Matching names or numeric addresses alone should not be promoted into a cross-provider correspondence. The selected fixture and reported addresses do not establish other mappings or behavioral equivalence. No autonomous agent-selection or performance measurement was performed. Related: #8173.

<!-- gh-comment-id:6533934108 --> @morluto commented on GitHub (Oct 30, 2026): Real-provider follow-up on PR #8187 branch, macOS arm64, the same self-built unexecuted Mach-O, Ghidra 12.1.4 and Kuna 1.986: 1. In one MCP connection, `open_binary` with Ghidra and `analyze_function` with summary retained the complete `_evaluate` dossier. Explicitly opening the same target with Kuna and analyzing `_evaluate` retained a second dossier; the first reference still resolved after the switch. 2. `compare_functions` accepted both retained references. Both providers reported the same name and `0x100000430` in this fixture, but REA correctly returned ambiguous function identity and all eight dimensions unknown: in particular, the providers do not establish a common coordinate commitment or stable Kuna symbol origin, and their text is not a cross-provider invariant. 3. Exporting the session Evidence bundle preserved both source dossiers and comparison; after `close_binary` cleared session records, comparison by those IDs failed with actionable `evidence_integrity_mismatch`. Importing the bundle restored the same comparison Evidence ID. In a fresh MCP server, `get_evidence_bundle` summary discovered both dossiers and two `inspect_analysis_view` native-pseudocode pages retrieved each provider's actual text with parent references, coverage and limitations, without reopening a provider. This refines the original limitation: the current workflow **can** keep the observations together and recover both texts from retained or bundled Evidence, but it takes a provider switch, two analyses and separate views. A direct composition over already-retained dossiers may therefore be a smaller complementary design than always starting multiple engines; an acquisition workflow would still need separate provider lifecycles, partial failures, cancellation and preservation of the caller's existing binding. Matching names or numeric addresses alone should not be promoted into a cross-provider correspondence. The selected fixture and reported addresses do not establish other mappings or behavioral equivalence. No autonomous agent-selection or performance measurement was performed. Related: #8173.
bsakaguchi commented 2026-11-01 21:10:53 +00:00
Author
Owner
Copy link

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

Real cross-provider disagreement and existing manual corroboration

On current REA a989c0e, real Ghidra 12.1.4 and Kuna 1.986 analyzed an explicitly selected, source-built x86-64 ELF containing audit_select. The function has one unconditional write and a conditional return. Kuna rendered a second write on one return path; Ghidra rendered one. Independent instruction listing and REA's Ghidra inspect_native_instruction show the single MOV write at 0x101377 followed by a conditional move and return. Direct Kuna and an ordinary non-IFUNC reduction reproduce the upstream issue Kuna #1355.

The existing MCP workflow can retain both observations: open Ghidra, take an analyze_function summary, explicitly switch to Kuna and take its summary, then use each parent ID with inspect_analysis_view for pseudocode and assembly. Exporting the bundle, closing, and importing in a fresh target-free server reproduced all four normalized views exactly. compare_functions kept identity ambiguous and both text dimensions unknown; it did not attempt to flag the semantic discrepancy, consistent with its contract. The caller can manually inspect the differing pseudocode and instruction Evidence; this is not an automated verdict that one provider is correct.

Coordinates matter even for the same file: the format export reported ELF value 0x1370, Kuna's entry was 0x1370, and Ghidra's was 0x101370. Ghidra address_to_file_offset returned 0x370; independent ELF load headers map the source value to that file offset on this fixture. Kuna's assembly also included a trailing NOP outside Ghidra's displayed function body, so matching entry coordinates does not automatically establish equal extents. Those observations support a manual same-artifact handoff here, not general cross-provider correspondence.

This is a concrete example for the second-opinion task and its Evidence/coordinate tradeoffs, not a request to rank outputs or assert text equality. A provider switch can retire edited session state (#8289); the test made no edits. Fixture and exported bundle hashes stayed unchanged, no target was executed, and no autonomous agent or performance trial was run.

<!-- gh-comment-id:6545462727 --> @morluto commented on GitHub (Oct 31, 2026): ### Real cross-provider disagreement and existing manual corroboration On current REA `a989c0e`, real Ghidra 12.1.4 and Kuna 1.986 analyzed an explicitly selected, source-built x86-64 ELF containing `audit_select`. The function has one unconditional write and a conditional return. Kuna rendered a second write on one return path; Ghidra rendered one. Independent instruction listing and REA's Ghidra `inspect_native_instruction` show the single `MOV` write at `0x101377` followed by a conditional move and return. Direct Kuna and an ordinary non-IFUNC reduction reproduce the upstream issue [Kuna #1355](https://github.com/Noelo-Lab/kuna/issues/1355). The existing MCP workflow can retain both observations: open Ghidra, take an `analyze_function` summary, explicitly switch to Kuna and take its summary, then use each parent ID with `inspect_analysis_view` for pseudocode and assembly. Exporting the bundle, closing, and importing in a fresh target-free server reproduced all four normalized views exactly. `compare_functions` kept identity ambiguous and both text dimensions unknown; it did not attempt to flag the semantic discrepancy, consistent with its contract. The caller can manually inspect the differing pseudocode and instruction Evidence; this is not an automated verdict that one provider is correct. Coordinates matter even for the same file: the format export reported ELF value `0x1370`, Kuna's entry was `0x1370`, and Ghidra's was `0x101370`. Ghidra `address_to_file_offset` returned `0x370`; independent ELF load headers map the source value to that file offset on this fixture. Kuna's assembly also included a trailing NOP outside Ghidra's displayed function body, so matching entry coordinates does not automatically establish equal extents. Those observations support a manual same-artifact handoff here, not general cross-provider correspondence. This is a concrete example for the second-opinion task and its Evidence/coordinate tradeoffs, not a request to rank outputs or assert text equality. A provider switch can retire edited session state (#8289); the test made no edits. Fixture and exported bundle hashes stayed unchanged, no target was executed, and no autonomous agent or performance trial was run.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
codex/procedure-reference-stacked
release-please--branches--main--components--rea-agents
release-please--branches--main--components--rea-agents--release-notes
codex/kuna-independent-retry
codex/byte-search-overlay-coverage
codex/open-failure-target-receipt
codex/kuna-xref-evidence
codex/ghidra-ambiguous-procedure-recovery
codex/function-source-bundle
codex/trace-function-integration-prototype
codex/snapshot-source-closure
codex/recorded-evidence-array-pages
codex/evidence-recovery-redesign
codex/trace-feature-address-scope
codex/call-discovery-scope
codex/ghidra-literal-candidate-evidence
codex/decompile-directory-independent-retry
codex/retry-provenance-base
codex/value-flow-capability-experiment
codex/ghidra-containing-instruction
cursor/readme-discord-button-ef9f
dependabot/github_actions/actions/setup-node-7.1.0
dependabot/github_actions/actions/upload-artifact-7.0.2
dependabot/npm_and_yarn/npm-minor-and-patch-d8d97ce6df
codex/kuna-1989
fix/8559-native-ui-fixture-ownership
fix/8555-go-verifier-mcp-ownership
codex/provider-capability-recovery
fix/8642-rizin-target-stdin
codex/ghidra-memory-effect-scope
codex/ghidra-annotation-entry-selector
codex/ghidra-readonly-recovery
codex/ghidra-regex-verifier-recovery
codex/evidence-discovery-view-guidance
fix/8545-bulk-append-overflow
fix/8428-navigation-refusal-alternatives
codex/address-context-recovery
codex/matching-member-limitations
codex/unknown-scope-contract
codex/evidence-view-guidance
feat/8373-native-trace-views
codex/ghidra-snapshot-verifier-binding
codex/elf-export-visibility
codex/evidence-view-recovery
codex/native-reference-cli-help
codex/provider-candidate-observation-scope
codex/kuna-session-verification
codex/ghidra-switch-lifetime-guidance
codex/pseudocode-paging-discovery
codex/clarify-evidence-view-support
codex/kuna-xrefs-selector-recovery
codex/context-capacity-recovery
codex/evidence-closure-large-links
codex/same-function-evidence-identity
codex/ghidra-verifier-inspected-jdk
codex/audit-guided-workflows
codex/crash-prompt-retained-dossiers
codex/analysis-view-error-recovery
codex/kuna-verifier-target-selection
codex/ghidra-selected-project-call-coverage
codex/docs-native-analysis-scope
codex/ghidra-java-socket-boundary
codex/ghidra-retained-snapshot-verifier
codex/ghidra-search-inventory-facts
fix/8284-zero-argument-parameter-bindings
fix/8198-ui-action-handler-offset
fix/8257-elf-entry-label-identity
fix/8304-deferred-output-schema-projection
fix/8277-call-path-computed-target-uncertainty
fix/pr-8089-conflicts
fix/ci-static-duplicate-export
dependabot/npm_and_yarn/lint-staged-17.6.0
dependabot/github_actions/actions/download-artifact-8.0.2
dependabot/npm_and_yarn/write-file-atomic-8.0.0
dependabot/npm_and_yarn/canonicalize-5.1.0
dependabot/github_actions/actions/cache/restore-6.1.0
dependabot/npm_and_yarn/toon-format/toon-4.4.0
dependabot/github_actions/actions/deploy-pages-5.0.1
codex/review-fixes-pr-2403
codex/review-fixes-pr-2400
codex/process-terminal-width
codex/test-brittleness-cleanup
verify/7167-browser-connect-macos
fix/7167-browser-connect
feat/native-matching-allowance-setting
feat/browser-scenario-dry-run
test/managed-caller-parameters-20261024
codex/parser-fortythird-boundaries
fix/6926-pinvoke-platform-decorations-20261023
fix/6889-har-body-encoding-20261023
fix/6888-sqlite-schema-budget-20261023
fix/dependency-security-gates-6708
cursor/evidence-overwrite-rebase-b4ac
feat/4057-verify-native-exports
fix/windows-acl-observer-overhead-20261022
cursor/erlang-beam-restack-4476
cursor/pe-certificate-review-bf32
fix/6116-javascript-application-fs-errors
fix/6061-unmapped-runtime-script-unknown
feat/browser-scenario-summary
fix/pe-certificates
codex/verify-3407
cursor/rebase-5699
cursor/rebase-5352
cursor/rebase-5600
cursor/fix-cli-schema-omission-10a8
codex/audit-hopper-shutdown-reasons-20261021
fix/demangle-swift-omitted-record
fix/nib-boolean-value-types
cursor/cancellation-partial-observation-a5ac
fix/ib-object-limit-reasons
fix/electron-fuse-limit-advice
fix/kuna-doctor-dangling-cache
fix/fixed-budget-refusal-advice
fix/js-ipc-listener-dedup
fix/js-return-member-provenance
fix/dmg-integrity-retry-advice
fix/ida-doctor-readiness
fix/kuna-version-probe-output-drain
fix/legacy-swift-runtime-name-matching
fix/dylib-lazy-load-commands
fix/browser-scenario-startup-cancel
fix/swift-nested-punycode-classification
fix/compare-unselected-scopes
fix/objc-method-budget-coverage
fix/dmg-mounted-root-observations
audit/ci-tests-20261019-round2
release/6.7.0
fix/wabt-cleanup-retry-resolution
fix/electron-fuse-elf-pe-architecture
fix/native-plist-descriptor-ownership
fix/kuna-caller-cleanup-ownership
experiment/atomic-codemode-20261016
review/first-contributor-3776
fix/call-resolution-full-read-cycles
fix/member-mutation-selection-repeat
experiment/atomic-re-tools-20261015
perf/member-mutation-lazy-origins
perf/static-network-mutation-index
fix/hopper-startup-lifecycle
audit/3050-windows-proof-20261015
feat/windows-window-capture-2183
audit/3049-windows-proof-20261015
audit/3735-macos-fixtures-20261015
fix/batch-decompile-null-pseudocode
fix/kuna-inventory-honors-jobs
experiment/browser-codemode-tool-design-20261015
fix/hopper-clean-runtime-argv
codex/review-2049-27f1b367
review-fixes/pr-2787-routing
fix/3360-scoped-this-emitters
fix/3367-replaced-global-effects
fix/3838-compact-any-value-items
test/hopper-download-probe-20261015
codex/windows-runtime-creation-red-green-20261015
codex/windows-readonly-root-red-green-20261015
codex/windows-root-share-red-green-20261015
codex/exp-1685-win-mcp-startup
codex/bug-sweep-20261015
investigate/2190-windows-package-phases
investigate/3543-macos-cli-deadline
perf/3281-reverse-tools-feedback-quality
fix/3406-hopper-doctor-fixture
fix/3341-wrapper-require-test-context
fix/3301-owned-uninstall-fixtures
fix/3164-compiler-input-ownership
fix/pcap-cleanup-stdout-newline-20261014
perf/interface-builder-summary
codex/review-fixes-pr-1977
fix/ghidra-effective-jvm-platform
fix/docs-turkish-rust-link-20261013
fix/main-maintenance-ci-20261010
fix/recover-binary-session-process-effects
codex/review-fixes-pr-2457
codex/ci-required-cancellation-gate
fix/main-format-baseline-20261013
fix/setup-preserve-entry-fields
cursor/restore-main-checks-1ffc
fix/ghidra-bridge-hashmap-import
codex/shared-ci-jadx-json-default-20261013
codex/shared-ci-ghidra-test-groups-20261013
codex/shared-ci-java-fixture-format-20261013
codex/fix-intrinsic-invocation-boundaries
test/release-preflight-reusable-jobs
test/js-parameter-provenance-expectation
fix/linux-hopper-verification-current
test/2419-ghidra-elf-probe-size
followup/pr-1544-native-ida
codex/fold-pr-2230-contribution
docs/readme-responsible-use
fix/issue-2064
fix/issue-2050
fix/issue-2053
fix/issue-1968
fix/issue-1945
experiment/codemode-bridge-20261011
fix/tool-effects-negative-wording-1904-20261012
fix/1842-electron-interop-provenance
feat/recover-javascript-multi-input
refactor/website-i18n-prep
fix/nativeaot-pe-virtual-extent
fix/browser-verifier-ci-hang
fix/pe-resources-input-selection
docs/beginner-friendly-guides
docs/beginner-setup-guide
fix/javascript-analysis-worker-1563
fix/1649-ghidra-duplicate-names
fix/javascript-export-keys-integration-1369
test/maintenance-boundary-contracts-20261011
review/javascript-export-keys-1369
review/process-live-progress-1483
test/javascript-1495-growth-ratio
fix/ci-escape-timing
docs/normalized-terminal-geometry-1450
release/6.3.0
archive/release-6.3.0-pr1381
release/6.2.0
fix/electron-preload-dynamic-override
fix/javascript-self-referential-bundler-edges
release/6.1.0
cursor/grok-client-cherry-pick-0b56
feat/signature-posture
feat/dyld-shared-cache
feat/artifact-integrity-policy
feat/pkg-inventory
release/6.0.0
chore/sync-release-5.0.0
release/5.0.0
cursor/cloud-agent-node-787e
fix/javascript-xhr-open-endpoints
review/pr-711-realpath-fallback-wording
cleanup/replay-confinement
codex/test-suite-performance
codex/issue-foundations
codex/address-open-issues-2026-07-20
agent/javascript-vite-rollup-esbuild-adapters
agent/process-cleanup
agent/triage-integration
agent/unknown-commands-registry
feat/mcp-identity-metadata
morlvps/issue_cleanup
codex/installer-redesign
morl/roadmap-investigation-core
morl/roadmap-investigation-docs
release-please--branches--main--components--rea
rea-agents-6.8.0
rea-agents-6.7.0
rea-agents-6.6.0
experiment/atomic-codemode-wait-runtime-20261016
rea-agents-6.5.0
rea-agents-6.4.0
rea-agents-6.3.0
rea-agents-6.2.0
rea-agents-6.1.0
rea-agents-6.0.0
rea-agents-5.0.0
rea-agents-4.1.0
rea-agents-4.0.1
rea-agents-4.0.0
rea-agents-3.2.1
rea-agents-3.2.0
rea-agents-3.1.0
rea-agents-3.0.0
rea-agents-2.7.0
rea-agents-2.6.0
rea-agents-2.5.1
rea-agents-2.5.0
rea-agents-2.4.0
rea-agents-2.3.0
rea-agents-2.2.0
rea-agents-2.1.0
rea-agents-2.0.0
rea-agents-1.7.0
rea-agents-1.6.0
rea-agents-1.5.0
rea-agents-1.4.0
rea-agents-1.3.0
rea-agents-1.2.0
rea-agents-1.1.0
rea-agents-1.0.0
rea-agents-0.5.0
rea-agents-0.4.0
rea-agents-0.3.0
rea-0.2.1
rea-0.2.0
Labels
Clear labels   
area: bridge

   
area: bridge

   
area: build

   
area: build

   
area: build

   
area: cli

   
area: domain

   
area: evidence

   
area: mcp

   
area: native

   
area: providers

   
area: runtime

   
area: server

   
area: setup

   
area: tests

   
bug

   
design

   
documentation

   
enhancement

   
enhancement

   
enhancement

   
experiment

   
help wanted

   
i18n

   
invalid

   
P0: critical

   
P1: high

   
P2: medium

   
P2: medium

   
P2: medium

   
P3: low

   
performance

   
provider-request

   
pull-request
Mirrored from GitHub Pull Request

  
question

   
roadmap

   
triage
No labels
area: bridge
area: bridge
area: build
area: build
area: build
area: cli
area: domain
area: evidence
area: mcp
area: native
area: providers
area: runtime
area: server
area: setup
area: tests
bug
design
documentation
enhancement
enhancement
enhancement
experiment
help wanted
i18n
invalid
P0: critical
P1: high
P2: medium
P2: medium
P2: medium
P3: low
performance
provider-request
pull-request
question
roadmap
triage
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#764
No description provided.