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 #2483] [Design] macOS: every REA process recompiles the ownership helper (~380 ms, 34–47% of short CLI commands) #826

New issue
Closed
opened 2026-10-15 18:28:48 +00:00 by bsakaguchi · 2 comments
bsakaguchi commented 2026-10-15 18:28:48 +00:00
Owner
Copy link

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

Originally assigned to: @kaoru0822-kitauji on GitHub.

Summary

On macOS, the first owned command in every REA process compiles bridge/process/ProcessRunTokenReader.swift and ProcessRunTokenReaderMain.swift with xcrun swiftc into a fresh temporary root (createDarwinProcessRunTokenReader in src/process/DarwinProcessRunTokenReader.ts). The compiled reader is deleted when the process exits. The MCP server pays this once per server. The CLI pays it on every command, and on short static commands it is the largest single cost.

Changing this means persisting or shipping an executable that ownership decisions rely on, which is an architecture and authority decision. So I'm opening an issue with data instead of a PR, as CONTRIBUTING asks.

Measurements

Main at a6efa4fce, macOS 26 (Apple silicon), Xcode Command Line Tools (no full Xcode), Node 26.5.0, local build, idle machine. All values are medians of 3 runs. The Swift module cache was warm, as in normal use. #1137 measured an 18 s fully cold compile.

Wall time
rea inspect-macho /bin/ls --format json 1,124 ms
rea inspect-signature /bin/ls --format json 880 ms
rea list-architectures /bin/ls --format json 801 ms
xcrun swiftc of the two reader sources alone 378 ms

So the helper compile is 34% / 43% / 47% of those three commands.

I logged the spawn trace for one rea inspect-macho /bin/ls with a ChildProcess.prototype.spawn hook:

Process Count Each
xcrun swiftc …ProcessRunTokenReader*.swift 1 376 ms
ps -axo pid=,ppid=,pgid=,uid=,stat=,command= 15 15–16 ms
xcrun --find <tool> 8 5 ms
the analysis tools themselves (otool, nm, dyld_info ×2, lipo, file, …) 8 2–5 ms

The ownership ps sweeps (about 230 ms here) are a second, smaller cost: roughly one sweep per supervised launch, each 3–7× the duration of the command it supervises.

In an MCP server, the compile shows up only on the first native call. inspect_macho on /bin/ls takes about 755 ms cold versus 350 ms warm, and in-process timing of the first resolveXcrunTool call is 398 ms versus 21 ms.

Related

  • #1137 / #1139: an 18 s fully cold compile exhausted deadlines. That was fixed by deadline handling, not by reuse.
  • #2184: the compile deadline under load. A commenter there suggested a content-hashed cache or precompilation, without data.

Options (for maintainers to choose)

  1. Per-user, content-addressed cache. Key it on the source digest, the compiler and SDK identity, and the architecture, under a REA-owned 0700 directory. Before every exec, verify owner, mode and non-symlink. Publish with an atomic rename, and recompile on any mismatch. This removes the compile from every process after the first. Open questions: the trust given to a persisted executable that a same-user process could replace (it decides ownership before signals and cleanup), cache lifecycle under rea setup / rea uninstall, and recording which helper build produced the ownership facts.
  2. Compile once at rea setup (or doctor) into a REA-owned location, using the same verification as option 1 and falling back to the per-process compile. This makes setup the explicit owner of the artifact. It still needs the same integrity checks.
  3. Keep the per-process compile and reduce the ps sweeps. For example, read the process table through the already-compiled sysctl helper, or sweep once per batch of commands. This doesn't help the compile, but it removes about 15 ms × N launches from every operation, CLI and MCP alike.

Committing a prebuilt binary isn't an option (binaries must not be committed).

Not measured

  • A loaded machine (#2184) or a fully cold Swift module cache (#1137). Both make the compile much slower than here.
  • Full Xcode installs.
  • Linux and Windows ownership paths, which don't compile this helper.

AI agent note

An AI agent (Claude Code) collected these measurements and wrote this issue during a scheduled maintenance loop. It made no code changes for this issue.

Originally created by @kaoru0822-kitauji on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2483 Originally assigned to: @kaoru0822-kitauji on GitHub. ### Summary On macOS, the first owned command in every REA process compiles `bridge/process/ProcessRunTokenReader.swift` and `ProcessRunTokenReaderMain.swift` with `xcrun swiftc` into a fresh temporary root (`createDarwinProcessRunTokenReader` in `src/process/DarwinProcessRunTokenReader.ts`). The compiled reader is deleted when the process exits. The MCP server pays this once per server. The CLI pays it on every command, and on short static commands it is the largest single cost. Changing this means persisting or shipping an executable that ownership decisions rely on, which is an architecture and authority decision. So I'm opening an issue with data instead of a PR, as CONTRIBUTING asks. ### Measurements Main at a6efa4fce, macOS 26 (Apple silicon), Xcode Command Line Tools (no full Xcode), Node 26.5.0, local build, idle machine. All values are medians of 3 runs. The Swift module cache was warm, as in normal use. #1137 measured an 18 s fully cold compile. | | Wall time | | --- | ---: | | `rea inspect-macho /bin/ls --format json` | 1,124 ms | | `rea inspect-signature /bin/ls --format json` | 880 ms | | `rea list-architectures /bin/ls --format json` | 801 ms | | `xcrun swiftc` of the two reader sources alone | 378 ms | So the helper compile is 34% / 43% / 47% of those three commands. I logged the spawn trace for one `rea inspect-macho /bin/ls` with a `ChildProcess.prototype.spawn` hook: | Process | Count | Each | | --- | ---: | ---: | | `xcrun swiftc …ProcessRunTokenReader*.swift` | 1 | 376 ms | | `ps -axo pid=,ppid=,pgid=,uid=,stat=,command=` | 15 | 15–16 ms | | `xcrun --find <tool>` | 8 | 5 ms | | the analysis tools themselves (`otool`, `nm`, `dyld_info` ×2, `lipo`, `file`, …) | 8 | 2–5 ms | The ownership `ps` sweeps (about 230 ms here) are a second, smaller cost: roughly one sweep per supervised launch, each 3–7× the duration of the command it supervises. In an MCP server, the compile shows up only on the first native call. `inspect_macho` on `/bin/ls` takes about 755 ms cold versus 350 ms warm, and in-process timing of the first `resolveXcrunTool` call is 398 ms versus 21 ms. ### Related - #1137 / #1139: an 18 s fully cold compile exhausted deadlines. That was fixed by deadline handling, not by reuse. - #2184: the compile deadline under load. A commenter there suggested a content-hashed cache or precompilation, without data. ### Options (for maintainers to choose) 1. **Per-user, content-addressed cache.** Key it on the source digest, the compiler and SDK identity, and the architecture, under a REA-owned 0700 directory. Before every exec, verify owner, mode and non-symlink. Publish with an atomic rename, and recompile on any mismatch. This removes the compile from every process after the first. Open questions: the trust given to a persisted executable that a same-user process could replace (it decides ownership before signals and cleanup), cache lifecycle under `rea setup` / `rea uninstall`, and recording which helper build produced the ownership facts. 2. **Compile once at `rea setup` (or `doctor`)** into a REA-owned location, using the same verification as option 1 and falling back to the per-process compile. This makes setup the explicit owner of the artifact. It still needs the same integrity checks. 3. **Keep the per-process compile and reduce the `ps` sweeps.** For example, read the process table through the already-compiled sysctl helper, or sweep once per batch of commands. This doesn't help the compile, but it removes about 15 ms × N launches from every operation, CLI and MCP alike. Committing a prebuilt binary isn't an option (binaries must not be committed). ### Not measured - A loaded machine (#2184) or a fully cold Swift module cache (#1137). Both make the compile much slower than here. - Full Xcode installs. - Linux and Windows ownership paths, which don't compile this helper. ### AI agent note An AI agent (Claude Code) collected these measurements and wrote this issue during a scheduled maintenance loop. It made no code changes for this issue.
bsakaguchi commented 2026-10-31 00:29:43 +00:00
Author
Owner
Copy link

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

6.8.0 data point: this cost grew in 6.8.0. Published rea-agents@6.8.0 vs 6.7.0, macOS 26.7.1 arm64, Command Line Tools, Node 24.22.1. Medians of 5 alternating runs. The host was not idle (another agent session was running jobs), so absolute numbers are noisy, but both versions were interleaved.

Command (Calculator.app unless noted) 6.7.0 6.8.0 Change
inspect-plist 0.92 s 1.39 s +51%
inspect-signature 1.00 s 1.51 s +51%
inspect-macho 1.11 s 1.57 s +41%
inspect-sqlite-database (53 KB DB) 0.80 s 1.25 s +56%
inspect-go-binary (no native command) 0.38 s 0.43 s +13%

Where the extra time goes (child-process trace from a ChildProcess.prototype.spawn preload, inspect-plist):

6.7.0: xcrun swiftc …/ProcessRunTokenReader*.swift -o $TMPDIR/rea-process-token-*/reader   447 ms
       xcrun --find file; ps -axo …; file -b …; ps -axo …; xcrun --find plutil; ps -axo …; plutil …; ps -axo …
6.8.0: xcrun swiftc … (same)                                                               469 ms
       xcrun --find file; ps -axo …; reader --identities 1 323 324 …                       317–324 ms  ← new
       file -b …; ps -axo …; reader --identities …                                          6 ms
       (every later ps snapshot is followed by reader --identities, ~6 ms each)

6.7.0 compiles the reader but never executes it on this path. 6.8.0 now runs reader --identities <all ps PIDs> after every ps snapshot, and the first exec of the freshly compiled, unsigned binary costs about 320 ms. That's consistent with the first-launch policy check on a new executable. Later execs cost about 6 ms. A CPU profile shows matching idle time: 914 ms vs 596 ms.

So short native-command CLI calls now pay about 0.5 s (compile) plus 0.32 s (first exec), on every invocation. MCP pays it once per server. Persisting or reusing the reader across invocations would remove both costs.

<!-- gh-comment-id:6396240766 --> @kaoru0822-kitauji commented on GitHub (Oct 25, 2026): 6.8.0 data point: this cost grew in 6.8.0. Published `rea-agents@6.8.0` vs `6.7.0`, macOS 26.7.1 arm64, Command Line Tools, Node 24.22.1. Medians of 5 alternating runs. The host was not idle (another agent session was running jobs), so absolute numbers are noisy, but both versions were interleaved. | Command (Calculator.app unless noted) | 6.7.0 | 6.8.0 | Change | |---|---|---|---| | `inspect-plist` | 0.92 s | 1.39 s | +51% | | `inspect-signature` | 1.00 s | 1.51 s | +51% | | `inspect-macho` | 1.11 s | 1.57 s | +41% | | `inspect-sqlite-database` (53 KB DB) | 0.80 s | 1.25 s | +56% | | `inspect-go-binary` (no native command) | 0.38 s | 0.43 s | +13% | Where the extra time goes (child-process trace from a `ChildProcess.prototype.spawn` preload, `inspect-plist`): ``` 6.7.0: xcrun swiftc …/ProcessRunTokenReader*.swift -o $TMPDIR/rea-process-token-*/reader 447 ms xcrun --find file; ps -axo …; file -b …; ps -axo …; xcrun --find plutil; ps -axo …; plutil …; ps -axo … 6.8.0: xcrun swiftc … (same) 469 ms xcrun --find file; ps -axo …; reader --identities 1 323 324 … 317–324 ms ← new file -b …; ps -axo …; reader --identities … 6 ms (every later ps snapshot is followed by reader --identities, ~6 ms each) ``` 6.7.0 compiles the reader but never executes it on this path. 6.8.0 now runs `reader --identities <all ps PIDs>` after every `ps` snapshot, and the first exec of the freshly compiled, unsigned binary costs about 320 ms. That's consistent with the first-launch policy check on a new executable. Later execs cost about 6 ms. A CPU profile shows matching idle time: 914 ms vs 596 ms. So short native-command CLI calls now pay about 0.5 s (compile) plus 0.32 s (first exec), on every invocation. MCP pays it once per server. Persisting or reusing the reader across invocations would remove both costs.
bsakaguchi 2026-11-01 21:10:52 +00:00
bsakaguchi commented 2026-11-01 21:10:53 +00:00
Author
Owner
Copy link

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

Re-measured on main 23de10bb2 (macOS 26 arm64, Command Line Tools, Node 24.22.1). Child-process trace of one rea inspect-macho /bin/ls --json, total 1,427 ms:

+408 ms  xcrun swiftc …/ProcessRunTokenReader.swift …ProcessRunTokenReaderMain.swift -o $TMP/rea-process-token-*/reader
+325 ms  $TMP/rea-process-token-*/reader --identities …   ← first exec of the fresh binary
  +4–7 ms each for the 11 later reader execs; ps sweeps 14–28 ms each

Compile plus first exec is 733 ms, or 51% of the command. I'm taking this on with option 1 and a deliberately narrow trust story:

Proposal: a per-user, content-addressed helper cache, with fail-closed verification and the current compile as the fallback.

  • Location: ~/Library/Caches/rea/process-helper/<key>/. HOME comes from the launch environment, next to the existing ~/Library/Caches/rea/kuna. The process ownership host turns it on in production. Readers created directly (tests) stay uncached unless they pass a directory.
  • Key: sha256 over a helper-format version, the bytes of both Swift sources, the compiler selection (xcrun, or REA_DARWIN_SWIFTC_PATH + SDKROOT), process.arch and os.release(). An OS update or a helper source change gives a new key. No extra compiler subprocess is spawned to build the key.
  • Publish: compile into a fresh mkdtemp staging directory inside the cache root, so the rename stays on one filesystem. Write a manifest with the binary's sha256 and the key inputs, then atomically rename the staging directory to <key>. If another process published first, verify and use its entry, then remove our staging directory.
  • Use (once per process, before the first exec): lstat the cache root, the <key> directory and reader. All must be owned by the current uid, not symlinks, not group- or world-writable, and reader must be a regular executable file. The manifest must parse, its key must match, and the binary digest must match. Any failure means the entry is never executed.
  • Fallback: if anything about the cache is unavailable, the reader uses today's per-process temp compile with unchanged cleanup semantics. That includes an unset or relative HOME, EACCES/EROFS/ENOSPC, a foreign or loosened entry, or a digest mismatch. Cache problems never fail an ownership operation. A REA-owned entry that fails validation is removed (Malformed owned data may still be safely removable). Entries with foreign ownership or modes are left alone, but are not executed.
  • Lifecycle: close() and process exit remove only per-process staging and temp roots, never a published entry. Nothing is pruned automatically, because removing an entry another live REA process may still exec would turn a cache into an ownership failure. Growth is one ~100 KB entry per helper-source × OS-release × compiler × arch combination. The location is documented, and it is safe to delete while no REA process runs.
  • Trust: this adds no new boundary. Today's helper already lives for the whole process, which is days for an MCP server, in a same-user 0700 temp root, and REA's own JavaScript is equally same-user-writable. The checks reject accidental or foreign corruption and loosened permissions. They don't claim to stop a same-user attacker. TOCTOU between verification and exec is the same same-user class and stays out of scope.

Verification plan: module tests with a fake compiler for a hit (no compile), a miss (compile once, then publish), a concurrent publish race, a corrupt digest, a loosened mode, a symlink, a foreign key, an unwritable cache root (fallback), cancellation during compile (no published entry, staging removed), and close not removing the published entry. Plus the real xcrun swiftc boundary test and before/after CLI timings (cold first run vs warm) for inspect-macho, inspect-signature and inspect-plist.

<!-- gh-comment-id:6544486519 --> @kaoru0822-kitauji commented on GitHub (Oct 31, 2026): Re-measured on main `23de10bb2` (macOS 26 arm64, Command Line Tools, Node 24.22.1). Child-process trace of one `rea inspect-macho /bin/ls --json`, total 1,427 ms: ``` +408 ms xcrun swiftc …/ProcessRunTokenReader.swift …ProcessRunTokenReaderMain.swift -o $TMP/rea-process-token-*/reader +325 ms $TMP/rea-process-token-*/reader --identities … ← first exec of the fresh binary +4–7 ms each for the 11 later reader execs; ps sweeps 14–28 ms each ``` Compile plus first exec is 733 ms, or 51% of the command. I'm taking this on with option 1 and a deliberately narrow trust story: **Proposal: a per-user, content-addressed helper cache, with fail-closed verification and the current compile as the fallback.** - **Location**: `~/Library/Caches/rea/process-helper/<key>/`. HOME comes from the launch environment, next to the existing `~/Library/Caches/rea/kuna`. The process ownership host turns it on in production. Readers created directly (tests) stay uncached unless they pass a directory. - **Key**: sha256 over a helper-format version, the bytes of both Swift sources, the compiler selection (`xcrun`, or `REA_DARWIN_SWIFTC_PATH` + `SDKROOT`), `process.arch` and `os.release()`. An OS update or a helper source change gives a new key. No extra compiler subprocess is spawned to build the key. - **Publish**: compile into a fresh `mkdtemp` staging directory inside the cache root, so the rename stays on one filesystem. Write a manifest with the binary's sha256 and the key inputs, then atomically `rename` the staging directory to `<key>`. If another process published first, verify and use its entry, then remove our staging directory. - **Use (once per process, before the first exec)**: `lstat` the cache root, the `<key>` directory and `reader`. All must be owned by the current uid, not symlinks, not group- or world-writable, and `reader` must be a regular executable file. The manifest must parse, its key must match, and the binary digest must match. Any failure means the entry is never executed. - **Fallback**: if anything about the cache is unavailable, the reader uses today's per-process temp compile with unchanged cleanup semantics. That includes an unset or relative HOME, `EACCES`/`EROFS`/`ENOSPC`, a foreign or loosened entry, or a digest mismatch. Cache problems never fail an ownership operation. A REA-owned entry that fails validation is removed (`Malformed owned data may still be safely removable`). Entries with foreign ownership or modes are left alone, but are not executed. - **Lifecycle**: `close()` and process exit remove only per-process staging and temp roots, never a published entry. Nothing is pruned automatically, because removing an entry another live REA process may still exec would turn a cache into an ownership failure. Growth is one ~100 KB entry per helper-source × OS-release × compiler × arch combination. The location is documented, and it is safe to delete while no REA process runs. - **Trust**: this adds no new boundary. Today's helper already lives for the whole process, which is days for an MCP server, in a same-user 0700 temp root, and REA's own JavaScript is equally same-user-writable. The checks reject accidental or foreign corruption and loosened permissions. They don't claim to stop a same-user attacker. TOCTOU between verification and exec is the same same-user class and stays out of scope. Verification plan: module tests with a fake compiler for a hit (no compile), a miss (compile once, then publish), a concurrent publish race, a corrupt digest, a loosened mode, a symlink, a foreign key, an unwritable cache root (fallback), cancellation during compile (no published entry, staging removed), and close not removing the published entry. Plus the real `xcrun swiftc` boundary test and before/after CLI timings (cold first run vs warm) for `inspect-macho`, `inspect-signature` and `inspect-plist`.
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#826
No description provided.