One command catalog now spans very different actions
REA 6.4.0 publishes one CLI and Model Context Protocol server for native binaries, JavaScript and Electron applications, websites, Android packages and devices, saved captures, and other targets. The command list includes static inspection, browser and process observation, device file transfer, package installation, app launch, and app stop operations.[1][4]
That breadth is useful because one investigation can move from file structure to runtime behavior. It also makes the command name a poor approval unit. inspect-managed-artifact reads supplied metadata without loading target code. capture-process runs a selected process scenario. install-adb-package changes a device. Each route needs its own authority and cleanup plan.
Approve the action class, not the product name.
Local is not a sandbox
The project's security policy says its provider bridge uses a random capability token and a current-user Unix socket. It also says this does not protect against a malicious process running as the same operating-system user. Opening an untrusted binary delegates parsing and analysis to the selected provider with that user's permissions.[3]
The CLI guide draws a second line. Static JavaScript and .NET inspection read supplied files without running the application. Runtime capture launches or interacts with the selected target using the user's permissions.[1] A local route can keep data off a hosted service. It does not remove parser risk, target side effects, or access to the current account.
Availability and safety are separate records
REA's Model Context Protocol catalog lists the complete tool inventory, including tools that are unavailable in the current session. Its binary_session response reports which operations are available for the selected target, provider, host, and client capabilities.[2]
Availability answers whether the route can run. It does not answer whether the route should run on this target. Keep target ownership, allowed actions, network scope, credentials, retention, and stop conditions in a separate review packet.
A completed process can still return partial evidence
The CLI guide defines exit status zero as a completed operation. The result can still contain partial evidence, warnings, or unresolved questions.[1] This is the right contract for reverse engineering. A tool can finish its requested pass without proving the explanation built from that pass.
Save raw observations before writing the inference. Keep generated pseudocode tied to the analysis engine that produced it. Challenge the claim with another input, a neighboring path, a runtime replay, or an independent source. A fluent explanation is not an independent check.
Use three detents and four fuses
The keyway below separates static inspection, live observation, and mutating action. Four square fuses define the review packet. The browser-only rig does not connect to REA or inspect a target. Selecting every fuse means the template has all four sections. It does not grant authority or attach evidence.