[GH-ISSUE #8363] [Bug] Ghidra address context hides available function comments and suggests unsupported calls #6562

New issue

Open

opened 2026-11-01 21:12:16 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented 2026-11-01 21:12:16 +00:00

Owner

Copy link

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

Before submitting

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

Area

MCP or agent integration

Observed behavior

A Ghidra session can write and read regular and inline comments at a function entry via annotate_native_function and analyze_function, but inspect_address_context at that same entry reports both comment facets unavailable and tells the agent to call comment and inline_comment. Both suggested calls return non-retryable capability_unavailable for the active Ghidra provider.

Reproduction

1. Create an unexecuted raw x86-64 fixture with bytes e806000000b878563412c3b821436587c3. Start REA MCP with Ghidra 12.1.4 and call open_binary with format: "raw-binary", architecture: "x86_64", entry_point: "0x1000", and the fixture path.
2. Call annotate_native_function with {"procedure":"0x1000","comment":"analysis note: evidence marker","inline_comment":"instruction note: marker"}. The readback and refreshed dossier contain both comments.
3. Call inspect_address_context({"address":"0x1000"}). Both comment facets have state: "unavailable" with a reason that the provider does not declare the corresponding operation and a remediation to call that operation directly. comment({"address":"0x1000"}) and inline_comment({"address":"0x1000"}) each return capability_unavailable.
4. In the same session, analyze_function({"procedure":"0x1000","detail":"complete"}) independently returns both comments at 0x1000. The Ghidra session is ephemeral; the original fixture SHA-256 remains unchanged.

The bookmarks facet also advises calling unsupported list_bookmarks, but this experiment does not establish a supported way to retrieve Ghidra bookmarks. Requests used the public stdio MCP interface and advertised full output schemas with the TypeScript SDK.

Additional Mach-O control

On REA 7abef04a5, Ghidra 12.1.4, Node 24.22.1 and macOS arm64, an owned unexecuted arm64 Mach-O produced the same outcome at a function entry: after annotate_native_function set a name, regular comment Analyst note: café, and inline comment Review branch, address context reported the name but both comment facets unavailable with direct-call remediation. In the same live session, complete analyze_function returned both exact comments. The annotation response also carried both readbacks. The target SHA-256 87fa65dee009e59a8709a70a2aa731a0dc9cae47cf65d4c69292f7cad4897d93 remained unchanged. This extends the observed formats and architecture; it does not prove arbitrary-address support.

Expected behavior

The context workflow should make supported evidence and applicable recovery discoverable without claiming unsupported arbitrary-address comment access. For an address inside a known function, one possible recovery is to inspect that function's comment evidence and match the exact address; if a lighter or more direct representation is preferable, decide it at the owning boundary. Preserve unsupported/unknown outcomes for addresses where comments cannot be obtained, and do not automatically switch providers or imply absence. A caller should not be directed to an operation already known to be unavailable without making that limitation clear.

Impact and scope

An agent following the context response spends extra calls on operations guaranteed unavailable in this session and is not guided to the existing function dossier containing the comments. No autonomous-agent retry or frequency was measured. Tested one function entry, one raw x86-64 fixture and Ghidra 12.1.4 on macOS arm64; arbitrary addresses, other providers and Windows are unverified.

REA version

d54a4661da

Runtime and platform

Node 24.22.1; macOS 26.3 arm64; Ghidra 12.1.4 / JDK 21; TypeScript MCP SDK 2.3.1.

Target and artifact context

17-byte synthetic raw x86-64 fixture, SHA-256 58658a4b21d7ffc610f7123d0f4e9435c3ba63b54facea49da1bb9bb51cd8cc5; target unexecuted and unchanged.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

inspect_address_context comment facet: {"state":"unavailable","reason":"Provider ghidra cannot execute comment: operation is not declared by this provider","remediation":"Call comment directly to inspect provider availability and diagnostics."}. The inline facet is equivalent. analyze_function's complete dossier contains {"address":"0x1000","kind":"comment","text":"analysis note: evidence marker"} and the corresponding inline entry.

Analysis or suspected cause

Source-derived: AnalysisContextQueries.ts asks the individual comment and inline_comment operations and constructs the same direct-call remediation for unavailable facets. The dossier already provides function-scoped comment evidence; how to reuse it without unbounded collection, implicit fallback, or losing address/provenance is a design question.

Additional context

Related #6404 requests arbitrary-address Ghidra comment operations. This issue concerns surfacing or navigating to evidence already available for a known function entry and avoiding guaranteed-unavailable recovery, independently of whether those broader operations are implemented. #8241 concerns instruction containment for search hits.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Existing-project Function ID comment control

On REA 9ebbe67e, Ghidra 12.1.4 and an explicitly selected copied project, a complete analyze_function dossier for 0x201170 contained the ordinary comment Library Function - Single Match, audit_mix, and Library: fixture 1 control. In the same session, inspect_address_context correctly identified the containing audit_mix function but reported the comment facet unavailable and recommended calling unsupported comment; this held in compact and full MCP output profiles. The original unexecuted x86-64 ELF target SHA-256 stayed 0cee46f9e95af174dec7f281c179cbe5233348520302c69fdc9eafc7fcebff1d.

The comment was present in the selected project before the REA session; no annotation call was made in this control. This is another case where existing function-scoped comment evidence is discoverable through the dossier but not the address-context recovery. The text is a Ghidra project comment, not authenticated proof of database identity or behavioral equivalence. This does not establish support at arbitrary addresses or measure agent behavior.

Interior-address distinction

In the same selected-project control, querying inspect_address_context at 0x201171 resolved the containing function entry 0x201170 in both output profiles. The separately retrieved dossier's Function ID comment is explicitly at 0x201170, not the requested interior address. The context's comment facet remained unavailable. The target digest was unchanged. A recovery path can navigate to the containing dossier, but must compare exact addresses and must not project this entry comment onto the interior address or infer that no interior comment exists. Source inspection also shows AnalysisOperationPort exposes execution but not operation availability, so suggesting the dossier as guaranteed requires an appropriate capability source or an explicit conditional, rather than assuming every provider supports it.

Known interior comment control

I copied the prior Ghidra project to a disposable project, used Ghidra headless to add the EOL comment interior review marker at 0x201171, and selected that copied project in fresh REA/Ghidra MCP sessions. In both compact and full profiles, complete analyze_function returned the marker as an inline comment at that exact interior address, alongside the distinct entry comment. inspect_address_context at 0x201171 still marked inline_comment unavailable and suggested the unsupported direct operation. The original target SHA-256 remained 0cee46f9e95af174dec7f281c179cbe5233348520302c69fdc9eafc7fcebff1d; it was not executed. Only the disposable project was edited in preparation.

This confirms a useful existing dossier path for one known interior comment, while exact-address matching remains necessary. It does not prove every provider or every comment type is supported, or that absence from a dossier is proof of absence.

Summary and paged recovery

With the disposable interior-comment project above, analyze_function using its default summary returned a summary with two comments counted, rather than the comment texts. In the same server, passing the summary's parent_evidence_id as retained Evidence to inspect_analysis_view with {kind: "native", facet: "comments", offset: 0, limit: 10} returned the entry and exact interior comments, with an exhausted two-item page. This worked in compact and full output profiles and the unexecuted target digest remained unchanged. Complete dossier output is another tested route; the paged route avoids requiring the complete dossier inline, although the underlying Ghidra analysis still constructs the function dossier. Recovery guidance should distinguish a summary from its parent and honor pagination and facet availability; a comment count alone cannot identify an address or text.

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8363 ### 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 MCP or agent integration ### Observed behavior A Ghidra session can write and read regular and inline comments at a function entry via `annotate_native_function` and `analyze_function`, but `inspect_address_context` at that same entry reports both comment facets unavailable and tells the agent to call `comment` and `inline_comment`. Both suggested calls return non-retryable `capability_unavailable` for the active Ghidra provider. ### Reproduction 1. Create an unexecuted raw x86-64 fixture with bytes `e806000000b878563412c3b821436587c3`. Start REA MCP with Ghidra 12.1.4 and call `open_binary` with `format: "raw-binary"`, `architecture: "x86_64"`, `entry_point: "0x1000"`, and the fixture path. 2. Call `annotate_native_function` with `{"procedure":"0x1000","comment":"analysis note: evidence marker","inline_comment":"instruction note: marker"}`. The readback and refreshed dossier contain both comments. 3. Call `inspect_address_context({"address":"0x1000"})`. Both comment facets have `state: "unavailable"` with a reason that the provider does not declare the corresponding operation and a remediation to call that operation directly. `comment({"address":"0x1000"})` and `inline_comment({"address":"0x1000"})` each return `capability_unavailable`. 4. In the same session, `analyze_function({"procedure":"0x1000","detail":"complete"})` independently returns both comments at `0x1000`. The Ghidra session is ephemeral; the original fixture SHA-256 remains unchanged. The bookmarks facet also advises calling unsupported `list_bookmarks`, but this experiment does not establish a supported way to retrieve Ghidra bookmarks. Requests used the public stdio MCP interface and advertised full output schemas with the TypeScript SDK. ### Additional Mach-O control On REA `7abef04a5`, Ghidra 12.1.4, Node 24.22.1 and macOS arm64, an owned unexecuted arm64 Mach-O produced the same outcome at a function entry: after `annotate_native_function` set a name, regular comment `Analyst note: café`, and inline comment `Review branch`, address context reported the name but both comment facets unavailable with direct-call remediation. In the same live session, complete `analyze_function` returned both exact comments. The annotation response also carried both readbacks. The target SHA-256 `87fa65dee009e59a8709a70a2aa731a0dc9cae47cf65d4c69292f7cad4897d93` remained unchanged. This extends the observed formats and architecture; it does not prove arbitrary-address support. ### Expected behavior The context workflow should make supported evidence and applicable recovery discoverable without claiming unsupported arbitrary-address comment access. For an address inside a known function, one possible recovery is to inspect that function's comment evidence and match the exact address; if a lighter or more direct representation is preferable, decide it at the owning boundary. Preserve unsupported/unknown outcomes for addresses where comments cannot be obtained, and do not automatically switch providers or imply absence. A caller should not be directed to an operation already known to be unavailable without making that limitation clear. ### Impact and scope An agent following the context response spends extra calls on operations guaranteed unavailable in this session and is not guided to the existing function dossier containing the comments. No autonomous-agent retry or frequency was measured. Tested one function entry, one raw x86-64 fixture and Ghidra 12.1.4 on macOS arm64; arbitrary addresses, other providers and Windows are unverified. ### REA version d54a4661da20382ad8456564a08569fdd24131c5 ### Runtime and platform Node 24.22.1; macOS 26.3 arm64; Ghidra 12.1.4 / JDK 21; TypeScript MCP SDK 2.3.1. ### Target and artifact context 17-byte synthetic raw x86-64 fixture, SHA-256 `58658a4b21d7ffc610f7123d0f4e9435c3ba63b54facea49da1bb9bb51cd8cc5`; target unexecuted and unchanged. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence `inspect_address_context` comment facet: `{"state":"unavailable","reason":"Provider ghidra cannot execute comment: operation is not declared by this provider","remediation":"Call comment directly to inspect provider availability and diagnostics."}`. The inline facet is equivalent. `analyze_function`'s complete dossier contains `{"address":"0x1000","kind":"comment","text":"analysis note: evidence marker"}` and the corresponding `inline` entry. ### Analysis or suspected cause Source-derived: [`AnalysisContextQueries.ts`](https://github.com/morluto/rea/blob/d54a4661da20382ad8456564a08569fdd24131c5/src/application/AnalysisContextQueries.ts#L100-L155) asks the individual `comment` and `inline_comment` operations and constructs the same direct-call remediation for unavailable facets. The dossier already provides function-scoped comment evidence; how to reuse it without unbounded collection, implicit fallback, or losing address/provenance is a design question. ### Additional context Related #6404 requests arbitrary-address Ghidra comment operations. This issue concerns surfacing or navigating to evidence already available for a known function entry and avoiding guaranteed-unavailable recovery, independently of whether those broader operations are implemented. #8241 concerns instruction containment for search hits. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Existing-project Function ID comment control On REA `9ebbe67e`, Ghidra 12.1.4 and an explicitly selected copied project, a complete `analyze_function` dossier for `0x201170` contained the ordinary comment `Library Function - Single Match`, `audit_mix`, and `Library: fixture 1 control`. In the same session, `inspect_address_context` correctly identified the containing `audit_mix` function but reported the comment facet unavailable and recommended calling unsupported `comment`; this held in compact and full MCP output profiles. The original unexecuted x86-64 ELF target SHA-256 stayed `0cee46f9e95af174dec7f281c179cbe5233348520302c69fdc9eafc7fcebff1d`. The comment was present in the selected project before the REA session; no annotation call was made in this control. This is another case where existing function-scoped comment evidence is discoverable through the dossier but not the address-context recovery. The text is a Ghidra project comment, not authenticated proof of database identity or behavioral equivalence. This does not establish support at arbitrary addresses or measure agent behavior. ### Interior-address distinction In the same selected-project control, querying `inspect_address_context` at `0x201171` resolved the containing function entry `0x201170` in both output profiles. The separately retrieved dossier's Function ID comment is explicitly at `0x201170`, not the requested interior address. The context's comment facet remained unavailable. The target digest was unchanged. A recovery path can navigate to the containing dossier, but must compare exact addresses and must not project this entry comment onto the interior address or infer that no interior comment exists. Source inspection also shows `AnalysisOperationPort` exposes execution but not operation availability, so suggesting the dossier as guaranteed requires an appropriate capability source or an explicit conditional, rather than assuming every provider supports it. ### Known interior comment control I copied the prior Ghidra project to a disposable project, used Ghidra headless to add the EOL comment `interior review marker` at `0x201171`, and selected that copied project in fresh REA/Ghidra MCP sessions. In both compact and full profiles, complete `analyze_function` returned the marker as an `inline` comment at that exact interior address, alongside the distinct entry comment. `inspect_address_context` at `0x201171` still marked `inline_comment` unavailable and suggested the unsupported direct operation. The original target SHA-256 remained `0cee46f9e95af174dec7f281c179cbe5233348520302c69fdc9eafc7fcebff1d`; it was not executed. Only the disposable project was edited in preparation. This confirms a useful existing dossier path for one known interior comment, while exact-address matching remains necessary. It does not prove every provider or every comment type is supported, or that absence from a dossier is proof of absence. ### Summary and paged recovery With the disposable interior-comment project above, `analyze_function` using its default summary returned a summary with two comments counted, rather than the comment texts. In the same server, passing the summary's `parent_evidence_id` as retained Evidence to `inspect_analysis_view` with `{kind: "native", facet: "comments", offset: 0, limit: 10}` returned the entry and exact interior comments, with an exhausted two-item page. This worked in compact and full output profiles and the unexecuted target digest remained unchanged. Complete dossier output is another tested route; the paged route avoids requiring the complete dossier inline, although the underlying Ghidra analysis still constructs the function dossier. Recovery guidance should distinguish a summary from its parent and honor pagination and facet availability; a comment count alone cannot identify an address or text.

bsakaguchi added the

bug

triage

labels 2026-11-01 21:12:16 +00:00

bsakaguchi commented 2026-11-01 21:12:16 +00:00

Author

Owner

Copy link

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

Related handoff design: #8364 records that the aggregate context response does not link the successful component Evidence it retains, and its unavailable facets are not retained in that aggregate. The reproducer also checks two observations around a session-only name change and a successful export/import control. This is separate from making the Ghidra comment recovery useful.

<!-- gh-comment-id:6548098131 --> @morluto commented on GitHub (Oct 31, 2026): Related handoff design: #8364 records that the aggregate context response does not link the successful component Evidence it retains, and its unavailable facets are not retained in that aggregate. The reproducer also checks two observations around a session-only name change and a successful export/import control. This is separate from making the Ghidra comment recovery useful.

bsakaguchi commented 2026-11-01 21:12:16 +00:00

Author

Owner

Copy link

@morluto commented on GitHub (Nov 1, 2026):

A second real Ghidra control on main-derived REA confirms the existing narrower route works with the default summary as well as a complete dossier. On a separate source-owned, unexecuted arm64 Mach-O, annotate_native_function recorded a regular comment at the function entry and returned it in both its annotation readback and refreshed dossier. inspect_address_context still marked the comment facet unavailable and directed me to comment, which returned capability_unavailable. The default analyze_function summary did not include the text but counted one comment; inspect_analysis_view using normalized_result.parent_evidence_id and {kind: "native", facet: "comments"} returned the exact comment.

The stdio MCP calls used Ghidra 12.1.4 / JDK 21 on macOS arm64 and SDK 2.3.1 with advertised full output schemas; the target hash was unchanged. This is one entry address and does not establish arbitrary-address comment access or measure agent behavior.

<!-- gh-comment-id:6551870467 --> @morluto commented on GitHub (Nov 1, 2026): A second real Ghidra control on main-derived REA confirms the existing narrower route works with the default summary as well as a complete dossier. On a separate source-owned, unexecuted arm64 Mach-O, `annotate_native_function` recorded a regular comment at the function entry and returned it in both its annotation readback and refreshed dossier. `inspect_address_context` still marked the comment facet unavailable and directed me to `comment`, which returned `capability_unavailable`. The default `analyze_function` summary did not include the text but counted one comment; `inspect_analysis_view` using `normalized_result.parent_evidence_id` and `{kind: "native", facet: "comments"}` returned the exact comment. The stdio MCP calls used Ghidra 12.1.4 / JDK 21 on macOS arm64 and SDK 2.3.1 with advertised full output schemas; the target hash was unchanged. This is one entry address and does not establish arbitrary-address comment access or measure agent behavior.

bsakaguchi commented 2026-11-01 21:12:16 +00:00

Author

Owner

Copy link

@morluto commented on GitHub (Nov 1, 2026):

A cross-provider control affects the recovery design. On the same unexecuted arm64 Mach-O, Ghidra 12.1.4 resolved the function containing the test address; an address in the Mach-O header and an unmapped address were outside a function. Kuna 1.986 returned containment unavailable even at the known function, and its separately requested dossier explicitly reported analyst comments unavailable. The tested target hash was unchanged. This does not establish arbitrary-address behavior beyond those controls.

Draft #8414 therefore points to the existing function comments view only when containment is observed, and only conditionally on the tools and document being applicable. It retains unknown facets for the other cases and preserves provider-authored recovery. The PR also extends the real-Ghidra COM verifier to annotate both comment kinds and follow the MCP summary-to-comments-view route. It does not make comments directly available in inspect_address_context or resolve the Evidence handoff in #8364.

<!-- gh-comment-id:6551934639 --> @morluto commented on GitHub (Nov 1, 2026): A cross-provider control affects the recovery design. On the same unexecuted arm64 Mach-O, Ghidra 12.1.4 resolved the function containing the test address; an address in the Mach-O header and an unmapped address were outside a function. Kuna 1.986 returned containment unavailable even at the known function, and its separately requested dossier explicitly reported analyst comments unavailable. The tested target hash was unchanged. This does not establish arbitrary-address behavior beyond those controls. Draft #8414 therefore points to the existing function comments view only when containment is observed, and only conditionally on the tools and document being applicable. It retains unknown facets for the other cases and preserves provider-authored recovery. The PR also extends the real-Ghidra COM verifier to annotate both comment kinds and follow the MCP summary-to-comments-view route. It does not make comments directly available in `inspect_address_context` or resolve the Evidence handoff in #8364.

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

Subscribe

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

No description provided.