IPyIDA puts an IPython console inside IDA Pro

A REPL inside the disassembler, without a C extension

IPyIDA adds an IPython console to IDA Pro. Press Shift-. and a window opens with an embedded Qt console, and from there you get IPython's autocompletion, online help, a monospaced font input field and support for graphs.

The design decision that defines the project is that it is a Python only solution. Nothing is compiled, and there is no native component to build against IDA's SDK. The README is explicit that the author, as a non Windows IDA user, wanted something cross platform, and that although some implementation ideas came from an earlier project by another author, IPyIDA was written from scratch.

The practical consequence is installation. IDA already ships a Python interpreter, so a plugin that is only Python can be dropped into the plugins directory and run. A plugin needing a compiled extension would have to be rebuilt for each platform and each IDA version, which is exactly the friction the project avoids.

Compatibility is stated as IDA 6.6 and later on Windows, OS X and Linux, with testing done on IDA up to 9.2. The package is published on PyPI as ipyida.

One line in the IDA console does the whole install

The fast install path is a script run from the IDA console itself. For a Python 2 setup it is this:

import urllib2; exec urllib2.urlopen('https://github.com/eset/ipyida/raw/stable/install_from_ida.py').read()

and for Python 3 the urllib module is used instead:

import urllib.request; exec(urllib.request.urlopen('https://github.com/eset/ipyida/raw/stable/install_from_ida.py').read())

On macOS the Python3.framework does not ship a trusted CA file, so a variant passes the system certificate path explicitly:

import urllib.request; exec(urllib.request.urlopen('https://github.com/eset/ipyida/raw/stable/install_from_ida.py', cafile="/etc/ssl/cert.pem").read())

The script does four things: it installs pip if it is missing, installs the ipyida package from PyPI, copies ipyida_plugin_stub.py into the user's plugins directory, and loads the IPyIDA plugin. The README invites you to read the install_from_ida.py script yourself if you want to know exactly what it does, which is a reasonable thing to want when a line of code fetches and runs a remote file.

Upgrading is the same command again followed by a restart of IDA.

The manual route leaves dependency management to you

If you would rather not let a script fetch and install packages, the README describes the manual path. You copy ipyida_plugin_stub.py and the ipyida directory into IDA's plugins directory yourself.

The cost of that choice is stated in the documentation: this method requires that you manage dependencies on your own. IPyIDA needs the ipykernel and qtconsole packages, and it needs the qasync package as well if you are using ipykernel version 5 or newer.

That last condition catches people out, because ipykernel 5 is old enough that most current environments already have it. Without qasync in place the console has no working event loop integration with the Qt application, and the failure looks like a console that starts but does not behave.

For a locked down analysis machine where installing packages from PyPI is not an option, this manual route is the one that exists. It also means you are responsible for keeping ipykernel and qtconsole at versions that work together, which the automatic installer would otherwise handle.

A notebook attached to the live IDA session

IPyIDA ships a magic command called %open_notebook that opens a browser with a notebook attached to IPyIDA. The command takes care of installing dependencies on its first run and starting a Notebook server unless one is already running.

The detail worth knowing is that it reuses a server that is already up. If a Jupyter server is running when you invoke the magic, the notebook connects to it rather than starting a second one. The help for the command, available by typing %open_notebook?, lists further options.

This is the feature that changes the shape of a session. In a normal IDA workflow you write IDAPython into the console, run it, and read the output in a small pane. With a notebook you get cells, you can keep exploratory code in a document, and you can interleave prose with the calls into IDA.

There is a second README in the repository, README.virtualenv.adoc, which suggests the notebook route is considered important enough to document a virtual environment setup for it separately.

ipyidarc.py is the console's startup file

By default the console has no globals available at all. That is a deliberate choice rather than an oversight, and the mechanism for changing it is a file.

IPyIDA reads ipyidarc.py from the IDA user directory, whose path comes from idaapi.get_user_idadir(). Anything you import in that file is available in the IPython console when it opens. The README compares this to the idapythonrc.py file, which performs the same role for IDA's own Python.

The same file is where the dark theme configuration goes, which matters if you run IDA in a dark theme. The snippet calls into the qtconsole styles module and the ipyida.ida_qtconsole helper to set the widget options:

import qtconsole.styles
import ipyida.ida_qtconsole
ipyida.ida_qtconsole.set_widget_options(dict(
    style_sheet = qtconsole.styles.default_dark_style_sheet,
    syntax_style = qtconsole.styles.default_dark_syntax_style
))

PyCharm can drive the session instead of the Qt console

Among the features listed in the README, the one that is called noteworthy is IDE integration with PyCharm. The described workflow is to launch IDA and open a database, create a Jupyter Notebook in PyCharm, add some code, and click run, with IPyIDA handling the connection in the background.

What that buys is ordinary IDE behaviour while the analysis session is live: stepping through code, syntax highlighting and GitHub Copilot integration are named as examples. The alternative to consider is the other direction of the same connection.

IPyIDA also supports being driven from outside IDA. The README states that you can connect to the kernel outside of IDA using ipython console --existing, which means you can attach a separate terminal to a running IDA session.

That outside connection is the reason to think about IPyIDA for scripting rather than for interactive use. If your analysis is a script that runs against a database, having the same kernel reachable from a terminal, a notebook and the IDE means one session and one set of live objects rather than three separate processes.

A known failure mode on macOS and App Nap

The caveats section documents one real problem: an external console that stops responding when the IDA window has been in the background for too long.

The cause is macOS App Nap, from OS X 10.9 onwards, which throttles a backgrounded application. The documented workaround is to disable App Nap for IDA Pro, using two defaults write commands, one for the 32 bit bundle identifier and one for the 64 bit one:

defaults write com.hexrays.idaq   NSAppSleepDisabled -bool YES
defaults write com.hexrays.idaq64 NSAppSleepDisabled -bool YES

The README is candid about the trade. It calls the workaround a hack for now, notes that it uses more battery on a laptop, and says a better solution should be found.

Two details deserve attention. The commands affect the whole application rather than just IPyIDA, so this is a system wide change for IDA rather than a plugin preference. And the problem is specific to the external console case, which is the same feature that gives you the PyCharm and terminal integration, so the workaround and the useful feature land in the same place.

A custom licence and a Python only packaging path

The repository is not archived and the last push was on 2026-08-27, with release v2.3 tagged on 2026-06-19. The license is a custom one that GitHub cannot classify, with the details in the LICENSE file, so read that file rather than assuming an open source licence. The setup.py header says to see the LICENSE file for redistribution terms. This page offers no legal reading of it.

The packaging side is more interesting than a typical script installer. setup.py defines a custom setuptools command, HcliBuild, that creates a ZIP file for Hex-Rays' hcli to install the plugin, and the manifest it writes follows the ida-plugin JSON schema with an IDAMetadataDescriptorVersion of 1, an entry point of ipyida_plugin_stub.py, the version, the licence and the repository URL, plus a pythonDependencies entry pinning the package to its own version.

That means the plugin can be distributed in the plugin package format IDA's own tooling expects, rather than only as a directory you copy by hand. The same file also mentions a virtual environment README for the notebook route.

For a reverse engineering environment, the security picture is worth one sentence. The install path downloads and executes a script from a GitHub URL, and the console gives you a Python prompt inside your analysis tool with whatever privileges the analyst account has, so the plugin's trust boundary is the Python environment it runs in.

Editorial conclusion

IPyIDA is worth installing for anyone who scripts IDA with IDAPython, since autocompletion, online help and a real REPL inside the disassembler change how you work, and the %open_notebook magic gives you a notebook attached to the live IDA session. It is the wrong tool for a shared analysis environment where installing packages on analyst machines is not allowed, since the installer pulls from PyPI and modifies the plugins directory, and it does not work on IDA versions older than 6.6. Before installing, run the documented install_from_ida.py line from the IDA console, then check that ipyida_plugin_stub.py was copied into the plugins directory and that the console opens on Shift-.

Frequently asked questions

Official sources

1. eset/ipyida on GitHub
2. Issues
3. README
4. Releases