Rikugan: an LLM agent that lives inside IDA Pro and Binary Ninja

Not an MCP client: the agent runs inside the host process

The README answers the obvious question first, and the answer shapes everything else about the design. Rikugan is an agent built to live inside your reverse engineering host. It does not consume an MCP server to interact with the host database. It has its own agentic loop, its own context management, its own role prompt, whose source is given as rikugan/agent/system_prompt.py, and an in-process tool orchestration layer.

That last phrase is the important one. An external MCP client talks to the host over a protocol, from another process, with the round trip and the serialization that implies. Rikugan sits in the same process as the disassembler and drives the host through its own Python API, which is why it can offer tools for decompiler output, cross-references, annotations, types and host-specific IL or microcode manipulation, and why the tool count is described as sixty plus.

The agent loop itself is described as a generator-based turn cycle. Each user message starts a stream, execute, repeat pipeline, where the model response is streamed token by token and tool calls are intercepted and dispatched as they arrive. On top of that the README lists automatic error recovery, mid-run user questions, plan mode for multi-step workflows, and message queuing.

The activation is deliberately unobtrusive. The features list says it is quick to enable, just hit Ctrl+Shift+I and the chat will appear, and the repository tree backs up the plugin story with ida-plugin.json, plugin.json, install_ida.sh, install_ida.bat, install_binaryninja.sh and install_binaryninja.bat. So there is a native plugin for each of the two hosts.

The primary language is Python, and the pyproject declares a package named rikugan at version 1.4.0 with dependencies pinned exactly: anthropic, openai, google-genai, mcp, tomli, cryptography and ida-domain. The mcp dependency is there for the MCP server integration feature, not for talking to the host.

Installation is a one-liner, and Windows needs one extra package

The install section gives a script per platform. On Linux and macOS:

curl -fsSL https://raw.githubusercontent.com/buzzer-re/Rikugan/main/install.sh | bash

and on Windows in PowerShell:

irm https://raw.githubusercontent.com/buzzer-re/Rikugan/main/install.ps1 | iex

The installer auto-detects whether you have IDA Pro, Binary Ninja, or both. Host-specific install steps, manual setup and configuration are pointed at the documentation site, and the repository also carries an ARCHITECTURE.md, a DEVELOPMENT.md, an AGENTS.md and an llms.txt.

The Windows note is the one that bites, and the README is emphatic about it. Windows users should install the latest Microsoft Visual C++ Redistributable 2015-2022 x64 before launching IDA, because Rikugan uses the PySide6 and Shiboken Qt bindings that IDA ships with, and an outdated VC++ runtime can cause a crash during startup. So the failure mode is not a plugin error, it is the host failing to open at all, which sends you looking in the wrong place.

The requirements list is otherwise short: IDA Pro 9.0 or newer with the Hex-Rays decompiler, or Binary Ninja in UI mode, Python 3.10 or newer, at least one LLM provider, and Windows, macOS or Linux.

There is a version wrinkle worth flagging. The README says Python 3.10 or newer, and the pyproject says requires-python >= 3.11, and the tooling config targets py311. The README also warns specifically about IDA Pro with Python 3.14 or newer: Shiboken has a known use-after-free bug, and although Rikugan includes a workaround, Python 3.10 is still the safest choice, with an upstream report linked. For a plugin that runs inside your disassembler, a crash caused by a binding bug is a crash that takes your analysis session with it, so the conservative choice is the one the author recommends.

Exploration spawns subagents, and the orchestrator synthesises

The exploration feature is the part of the design that borrows most visibly from how code agents work. The orchestrator maps the binary first, covering imports, exports, strings and key functions, and then spawns isolated subagents to analyse parts of it in parallel. Each subagent reports back and the orchestrator synthesises a complete picture.

The isolation is the point. A single context window that has to hold the whole binary plus every intermediate observation is the failure mode of LLM-assisted analysis, and splitting the work into subagents means each one sees a slice while the orchestrator holds the summary. The README includes a screenshot of exactly that arrangement, captioned as the orchestrator spawning subagents in parallel.

Two more features follow the same pattern of borrowing from coding agents. The /modify command is described as natural language patches, marked experimental, where you describe a change in plain English and Rikugan explores the binary, builds context and applies the patches. The README's example is a request to make a maze game easy by letting the player pass through walls, with an animation of the result. That is a demonstration of the mechanism rather than a recommendation, and applying a patch to a binary carries a different risk from editing source, which is why the feature carries an experimental label.

The /deobfuscation skill is experimental and Binary Ninja only. It activates plan mode and works on control flow flattening, opaque predicates, MBA expressions and junk code, using IL read and write primitives. The README quotes a figure of roughly three times the speed of the manual workflow, with the original process taking about four and a half minutes. Whether you get that on your own binary depends entirely on the obfuscation, and the number in the README comes from a demonstration the author ran, not from a benchmark suite.

Everything the agent does goes through the host's scripting, and the tool list makes that explicit: the agent always asks permission before running scripts and will never execute the target binary. That boundary is the safety property that matters most in a reverse engineering tool, and it is stated as a guarantee rather than a setting.

Memory is a markdown file, and skills come from elsewhere

Findings are saved to a file called RIKUGAN.md next to your database, and they persist across sessions. That is a deliberately simple persistence model, and it has a practical upside: the file is readable without the tool, diffable in version control, and portable between the two hosts, since it is not locked into a proprietary format.

The skills story is more interesting. There are twelve built-in skills, support for custom skills, and MCP server integration, and the point of the last item is reuse. You can reuse skills and MCP servers from Claude Code and Codex inside the disassembler, which means a workflow you already built for a coding agent can be brought to a reversing task without rewriting it.

Profiles sit alongside that. A profile lets you customise the agent to fit your analysis needs, and it gives granular control over which data the LLM can read, which tools it is allowed to use, and lets you define custom rules to filter data. The screenshot in the README shows the profile editor.

Profiles are the most important feature here for anyone who cares about where their data goes, and the reason is that an LLM inside a reverse engineering tool sees your binary. A binary under analysis may be a proprietary target, an unreleased build, or something covered by a non-disclosure agreement, and a profile that restricts which data the model can read is the mechanism for keeping the sensitive parts out of a remote provider's context. The README describes profiles in one paragraph and does not document a default, so the sensible assumption is that the default is broad and you should narrow it.

The recommended provider table is candid in a way that is useful. Claude Opus 4.6 is the recommended overall option, with a preference for a Claude Pro or Max plan over the API, and Claude Sonnet 4.6 is described as strong at lower cost with prompt caching in both Anthropic models. MiniMax M2.5 is reported as on par with Opus in local tests, Gemini is described as solid but hallucinating more, Kimi as strong at coding but lacking rigor for complex reversing work, and the large open weight models as interesting but not production-ready for reversing. Any OpenAI-compatible endpoint and Ollama for local models are also supported, so the local path exists for cases where nothing may leave the machine.

Engineering discipline in a project the author calls a work in progress

The tone of the conclusion is unusual and worth reading in full, because it sets expectations. The author says he completely changed his mind about AI doing reverse engineering, that Rikugan is one of many projects built in the last three months, that the first version was built in a single night, that within two days it already supported both IDA and Binary Ninja, and that within three days it was essentially what you see now, with only minor tweaks since. He also says this is a work in progress with many areas for improvement, and that he took care to ensure it would not be another AI slop project but is certain there is still room to grow.

The repository contents support the claim that some care was taken. The dev dependency group pins mypy, pytest, ruff and a tool called desloppify. The ruff configuration sets a line length of 120 and selects the E, W, F, I, UP, B and RUF rule sets, with per-file ignores for the Qt binding modules and for the specific files that contain ambiguous unicode characters. The mypy configuration targets Python 3.11, requires type annotations in the core and providers packages, and excludes the Qt bindings with an explicit comment explaining that the PySide6 import with a PyQt5 fallback is a redefinition by design and that the UI package sits outside the type-checked surface.

That comment is the kind of thing that separates a maintained project from a generated one. It records a decision, a reason and a consequence, which is exactly what a type checker configuration should carry.

The releases are v1.4.0 from 2026-09-25, v1.3.2 from 2026-06-15 and v1.3.1 from 2026-05-07, the last push was on 2026-10-12, and the repository is not archived. The licence is MIT with a LICENSE file at the root, and the package ships a chat_examples/ directory, a tests/ directory, a webpage/ directory for the documentation site and per-platform CI scripts, ci-local.sh and ci-local.ps1.

Where an LLM in a disassembler helps, and where it does not

The honest evaluation of a tool like this has to separate the parts that are genuinely new from the parts that are a repackaging of what a coding agent already does.

What is new is the integration. A model that can read the decompiler output of the function you are looking at, follow cross-references, jump to the string table and apply your own annotations, without leaving the host and without you pasting screenshots, removes a lot of context-switching from a task that is mostly context-switching. The exploration subagents and the orchestrator pattern address a real problem: a single long context is the weak point of LLM-assisted analysis.

What is not new is the reasoning. A model reading a decompiled function is doing the same thing it does when reading source. The author's own assessment is that the models differ in rigour and hallucination rate, and the table is a set of opinions about those differences rather than a measurement.

The failure mode to plan for is hallucination in a domain where the output looks authoritative. A model that invents a function name, a field offset or a call relationship will not look wrong in a chat window, and the fix is procedural rather than technical. The tool helps here in two ways: it always asks before running scripts, and it never executes the target binary. Both of those are stated guarantees, and they are what keeps a mistake in the analysis from becoming a mistake in the sample.

For anyone deciding, the practical order is to start with a profile that limits the model to reading, expand the tool permissions when you trust the output, and treat the experimental features as what they are. A natural language patch that rewrites a maze game's collision check is a demonstration; a natural language patch applied to something you care about is a research decision, not a shortcut.

Editorial conclusion

Adopt Rikugan if you already work in IDA Pro or Binary Ninja and want an LLM assistant that can read the same database you are reading, run the host's own scripting, and leave findings in a file you can review afterwards. Do not adopt it expecting an autonomous reverse engineer, because the author describes the project as a work in progress, the natural language patch and deobfuscation features are marked experimental, and the agent always asks before running scripts. Before you commit, install the latest Visual C++ Redistributable on Windows as the README insists, pick Python 3.10 rather than a newer release because of the documented Shiboken use-after-free bug, and start with a profile that restricts which data the model can read and which tools it can call, so that you can widen its access once you trust what it does.

Frequently asked questions

Official sources

1. buzzer-re/Rikugan on GitHub
2. License: MIT
3. Project website
4. README
5. Releases