REA 6.7.0 Adds Kuna Decompiler, Letting Coding Agents Reuse Static Analysis Results

REA released version 6.7.0 on October 18, incorporating features from 6.6.0, which had been tagged that day but not published to npm. These include the Kuna decompilation backend, reusable JavaScript analysis queries, and multilingual APK resource decoding. The update lets coding agents ask follow-up questions about the same analysis, reducing repeated runs of underlying tools. Release notes

REA gives agents code, references, and runtime observations to interpret. The official native code guide shows that agents need to cross-check instructions, callers, and constants to recover operations omitted from decompiled pseudocode. The traceability of analysis sources therefore directly affects the reliability of the reconstruction. Native analysis guide

The new Kuna backend performs static analysis: it reads the target image without executing it. Users must supply the executable, set REA_KUNA_COMMAND, and explicitly select the backend. REA can query functions, pseudocode, assembly, and call relationships. It identifies cached results using the target file, the Kuna executable’s hash and version, and the number of jobs. Output text also retains source files, byte ranges, and hashes, making it easier to trace the evidence cited by an agent. Kuna technical documentation

The cache also has semantic limitations: on a cold start, it can return a decompilation of a single function first; after the full project export is complete, the text for that same function may change. The official validation used Kuna 1.833 on Linux. Windows, PE, and generic Mach-O are not yet supported; type recovery and some low-level queries are also unavailable. Engineers should pin tool versions and settings, then check source markers to avoid treating outputs from different analysis stages as equivalent evidence. Kuna limitations and cache design

For agent workflows, another change lets users query selected paths, properties, and module references in an existing JavaScript analysis through inspect_analysis_view, with coverage information preserved. The technical benefit is that follow-up questions can build on completed work. Any actual savings in latency and model usage still need to be measured on each team’s projects. Version changes