morluto/rea

Fork 0

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

[GH-ISSUE #8302] [Bug] Compact Mach-O catalog omits slice-relative offset semantics #6534

New issue

Open

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

bsakaguchi commented

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

Owner

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

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

With REA_MCP_OUTPUT_SCHEMA_PROFILE=compact, the real tools/list definition for inspect_macho does not say that normalized entrypoint, segment and section file offsets are relative to the selected Mach-O slice, while architecture offsets and Evidence locations are relative to the input container. The returned result identifies the selected slice and its container offset, but neither the compact output schema, tool description nor this result's limitations states how to combine those values. The full advertised output schema does contain the field descriptions, and the repository documentation explains the distinction.

Reproduction

On macOS arm64, using REA b43c329 and the TypeScript MCP SDK, I opened a self-built x86-64/arm64 universal AppKit executable, called tools/list, then inspect_macho({detail:"complete"}) in both full and compact output-schema profiles. The SDK explicitly validated both successful inspection responses using their advertised tool definitions.

For the selected arm64 slice the result reported container_file_offset: 32768, __TEXT.vm_address: "0x100000000", and __TEXT.file_offset: 0. A known handler was at 0x100000784: the corresponding slice-relative offset is 1924; adding the slice base yields container offset 34692. A local file read at 1924 returned 0000000000000000; offset 34692 returned ff8300d1fd7b01a9, matching the same bytes in the selected thin slice. A separate successful Hopper-backed address_to_file_offset call returned container offset 34692, provider offset 1924 and image-base file offset 32768. The Evidence locations also used container offsets. The original app bytes were unchanged and not executed.

The full catalog schema included the descriptions Offset from the start of the selected Mach-O slice and Offset of the selected slice from the start of the input Mach-O container; the compact advertised output schema included neither. The common tool description did not explain the bases. One full-profile Hopper mapping attempt independently failed before bridge readiness and reported cleanup incomplete; the successful compact mapping and separate source-byte comparison above are the controls used for this observation.

Expected behavior

Make the coordinate origins discoverable in the compact-profile workflow, for example with a short tool-description or result-level explanation, while retaining the existing exact schema and source values. The full schema and native investigation guide already document the intended distinction. Preserve unknown slice identity and mapping ambiguity rather than guessing an offset.

Impact and scope

A caller treating a slice-relative number as an input-file offset can inspect the wrong bytes. The example demonstrates the different bytes and absent catalog explanation; no autonomous agent decision or error rate was measured. This is a compact-catalog discoverability gap, not a claim that the normalized values are incorrect. One universal fixture and macOS host were tested; output-schema-off and other clients were not tested.

REA version

b43c329df779708e43ae297f498a844e45d9c923 source build; relevant inspection/schema/guide source was unchanged at origin/main 23de10bb2849cdce8ddbe70504aa7cc57de75a98, which was not runtime tested.

Runtime and platform

Node 24.22.1, macOS arm64, TypeScript MCP SDK 2.3.1; Hopper was used only for the separate successful mapping control.

Target and artifact context

Self-built x86-64/arm64 universal AppKit executable, SHA-256 c90064a7d0ecf009323c54b36af3e6d1f7b8b8492a25ba4f8c26d3831ec57b70.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

selected_architecture.container_file_offset=32768; normalized __TEXT.file_offset=0; address 0x100000784; slice-relative offset 1924; input-container offset 34692. Full versus compact inspect_macho output-schema JSON lengths were 28,147 versus 1,159 bytes for this catalog; these are bytes, not model-token or latency measurements.

Typed outcome or recovery expected

The offset basis should remain available to callers who select compact output schemas. Keep the explicit selected slice, existing container-based Evidence locations, and a clear way to distinguish source bytes from loader-adjusted memory.

Additional context

Related: #1973 fixed the previous missing selected-slice identity and full-schema descriptions; this report does not dispute that fix. #7155 concerns catalog size, and #8170 concerns source versus provider-memory byte reads. No unknown last-known-good version is asserted.

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility.

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8302 ### 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 With `REA_MCP_OUTPUT_SCHEMA_PROFILE=compact`, the real `tools/list` definition for `inspect_macho` does not say that normalized entrypoint, segment and section file offsets are relative to the selected Mach-O slice, while architecture offsets and Evidence locations are relative to the input container. The returned result identifies the selected slice and its container offset, but neither the compact output schema, tool description nor this result's limitations states how to combine those values. The full advertised output schema does contain the field descriptions, and the repository documentation explains the distinction. ### Reproduction On macOS arm64, using REA `b43c329` and the TypeScript MCP SDK, I opened a self-built x86-64/arm64 universal AppKit executable, called `tools/list`, then `inspect_macho({detail:"complete"})` in both full and compact output-schema profiles. The SDK explicitly validated both successful inspection responses using their advertised tool definitions. For the selected arm64 slice the result reported `container_file_offset: 32768`, `__TEXT.vm_address: "0x100000000"`, and `__TEXT.file_offset: 0`. A known handler was at `0x100000784`: the corresponding slice-relative offset is 1924; adding the slice base yields container offset 34692. A local file read at 1924 returned `0000000000000000`; offset 34692 returned `ff8300d1fd7b01a9`, matching the same bytes in the selected thin slice. A separate successful Hopper-backed `address_to_file_offset` call returned container offset 34692, provider offset 1924 and image-base file offset 32768. The Evidence `locations` also used container offsets. The original app bytes were unchanged and not executed. The full catalog schema included the descriptions `Offset from the start of the selected Mach-O slice` and `Offset of the selected slice from the start of the input Mach-O container`; the compact advertised output schema included neither. The common tool description did not explain the bases. One full-profile Hopper mapping attempt independently failed before bridge readiness and reported cleanup incomplete; the successful compact mapping and separate source-byte comparison above are the controls used for this observation. ### Expected behavior Make the coordinate origins discoverable in the compact-profile workflow, for example with a short tool-description or result-level explanation, while retaining the existing exact schema and source values. The full schema and [native investigation guide](https://github.com/morluto/rea/blob/b43c329df779708e43ae297f498a844e45d9c923/docs/native-investigation.md) already document the intended distinction. Preserve unknown slice identity and mapping ambiguity rather than guessing an offset. ### Impact and scope A caller treating a slice-relative number as an input-file offset can inspect the wrong bytes. The example demonstrates the different bytes and absent catalog explanation; no autonomous agent decision or error rate was measured. This is a compact-catalog discoverability gap, not a claim that the normalized values are incorrect. One universal fixture and macOS host were tested; output-schema-off and other clients were not tested. ### REA version `b43c329df779708e43ae297f498a844e45d9c923` source build; relevant inspection/schema/guide source was unchanged at `origin/main` `23de10bb2849cdce8ddbe70504aa7cc57de75a98`, which was not runtime tested. ### Runtime and platform Node 24.22.1, macOS arm64, TypeScript MCP SDK 2.3.1; Hopper was used only for the separate successful mapping control. ### Target and artifact context Self-built x86-64/arm64 universal AppKit executable, SHA-256 `c90064a7d0ecf009323c54b36af3e6d1f7b8b8492a25ba4f8c26d3831ec57b70`. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence `selected_architecture.container_file_offset=32768`; normalized `__TEXT.file_offset=0`; address `0x100000784`; slice-relative offset 1924; input-container offset 34692. Full versus compact `inspect_macho` output-schema JSON lengths were 28,147 versus 1,159 bytes for this catalog; these are bytes, not model-token or latency measurements. ### Typed outcome or recovery expected The offset basis should remain available to callers who select compact output schemas. Keep the explicit selected slice, existing container-based Evidence locations, and a clear way to distinguish source bytes from loader-adjusted memory. ### Additional context Related: #1973 fixed the previous missing selected-slice identity and full-schema descriptions; this report does not dispute that fix. #7155 concerns catalog size, and #8170 concerns source versus provider-memory byte reads. No unknown last-known-good version is asserted. Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility.

bsakaguchi commented

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

Author

Owner

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

Installed-guidance recovery control

I checked the public rea guidance search/read workflow at b43c329, package rea-agents@6.8.0, after the compact-schema observation:

Query slice relative file offset returned one broad Native, managed, and packaged artifacts section. Reading it returned 49,189 content characters; it did not contain container_file_offset or a slice-relative offset explanation.
Query container_file_offset was tokenized as container, file, offset and returned three broad sections. Reading each did not return that exact field or the slice-relative rule; one search context concerned PE security-cookie and CFG offsets.
Query inspect_macho segment offset returned the same broad native/artifacts section. The relevant packaged passage describes inspect_macho summary and paging, but not the distinction between selected-slice and input-container file offsets.

This is a fixed-query, source-and-CLI control, not a measured agent failure rate or a claim that no external documentation exists. The repository's full docs/native-investigation.md does document the distinction, and the full output schema supplies the relevant field descriptions. A compact tool-description or targeted packaged guidance update could preserve the critical rule without reintroducing the entire output schema. The broad parent-section matching behavior is separately tracked in #8290; the coordinate-specific risk is the subject of this issue. Serialized read response sizes are not token measurements.

@morluto commented on GitHub (Oct 31, 2026): ### Installed-guidance recovery control I checked the public `rea guidance` search/read workflow at `b43c329`, package `rea-agents@6.8.0`, after the compact-schema observation: - Query `slice relative file offset` returned one broad `Native, managed, and packaged artifacts` section. Reading it returned 49,189 content characters; it did not contain `container_file_offset` or a slice-relative offset explanation. - Query `container_file_offset` was tokenized as `container`, `file`, `offset` and returned three broad sections. Reading each did not return that exact field or the slice-relative rule; one search context concerned PE security-cookie and CFG offsets. - Query `inspect_macho segment offset` returned the same broad native/artifacts section. The relevant packaged passage describes `inspect_macho` summary and paging, but not the distinction between selected-slice and input-container file offsets. This is a fixed-query, source-and-CLI control, not a measured agent failure rate or a claim that no external documentation exists. The repository's full `docs/native-investigation.md` does document the distinction, and the full output schema supplies the relevant field descriptions. A compact tool-description or targeted packaged guidance update could preserve the critical rule without reintroducing the entire output schema. The broad parent-section matching behavior is separately tracked in #8290; the coordinate-specific risk is the subject of this issue. Serialized read response sizes are not token measurements.

bsakaguchi commented

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

Author

Owner

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

Hi! I'd like to take this issue as a contribution.

I've reviewed the reproduction and traced the inspect_macho contract in src/contracts/native/nativeToolContracts.ts.

My proposed change is a focused clarification of the tool description, explicitly distinguishing:

Normalized entrypoint, segment and section file offsets relative to the selected Mach-O slice.
Architecture container offsets and Evidence locations relative to the original input file.

I'll keep this description-only, preserving the existing schemas, output values and parser behavior.

I'll also validate the change against the relevant MCP catalog checks before opening a PR.

@deepakrakshit commented on GitHub (Oct 31, 2026): Hi! I'd like to take this issue as a contribution. I've reviewed the reproduction and traced the `inspect_macho` contract in `src/contracts/native/nativeToolContracts.ts`. My proposed change is a focused clarification of the tool description, explicitly distinguishing: - Normalized entrypoint, segment and section file offsets relative to the selected Mach-O slice. - Architecture container offsets and Evidence locations relative to the original input file. I'll keep this description-only, preserving the existing schemas, output values and parser behavior. I'll also validate the change against the relevant MCP catalog checks before opening a PR.

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

No description provided.

Rows
Columns