Skip to content

Working with Multiple Binaries in a Project

Binary Ninja's project feature lets you group related binary files together. Sidekick is designed to work naturally with this workflow: when you open a project, all of its binaries share a single Sidekick workspace, giving Sidekick a unified view of your entire codebase.

How Sidekick maps to Binary Ninja projects

Sidekick organizes its data in workspaces. Each workspace stores the chat history, indexes, notebook entries, and semantic index for a set of related binaries.

The mapping rule is straightforward:

What you open in BN Sidekick workspace scope
A standalone .bndb or binary file One workspace per file
A Binary Ninja project One workspace shared by all files in the project

When you open a project, Sidekick creates (or reopens) a single workspace whose ID comes from the project's stable identifier. Every binary you open within the project is tracked by that workspace.

Note

Workspaces for standalone files use a content-based ID while they are unsaved and switch to a stable database-stored ID once saved as a .bndb. Project-backed workspaces always use the project's stable ID.

Note

If you later use File > Save As on an already-saved standalone .bndb, Sidekick treats the new file as a fork. It writes a fresh workspace ID and view IDs into the new file, copies your existing Sidekick data into that new workspace, and leaves the original file's workspace data untouched.

What is shared across all binaries

Because all binaries in a project share one workspace, the following data spans the entire project:

Chat history — every chat thread you start in the Sidekick Chat sidebar is stored in the shared workspace. You can ask questions about any binary in the project, and previous conversations about other binaries remain accessible in the same chat list.

Semantic index — the semantic index covers all open binaries. When you use semantic search (via concept() in a BNQL query or the Semantic Indexing panel), results can come from any binary in the project.

Notebook — the Notebook sidebar shows entries for the entire project workspace. When Sidekick opens a new binary file in a project, it automatically creates a binary profile notebook entry for that view. This entry records the filename, architecture, platform, entry point, and file size, and is updated as the file's state changes. The entry is marked closed when you close the file.

Indexes — manual indexes you build in the Indexes sidebar are stored per workspace. All indexes you create while working on the project are listed together regardless of which binary was active when you created them.

What is scoped to a specific binary

Some data is associated with a particular binary view rather than the workspace as a whole:

Current context — the active binary view (the one visible in the editor), the currently selected function, and the cursor address all belong to a specific binary. Chat and suggestion operations act on whichever binary is currently focused in the editor.

Semantic index scopes — each binary view is indexed as a separate scope within the shared semantic index. This scoping happens automatically when you open a binary; no configuration is required. Semantic search can retrieve results from multiple binaries in one response, and Sidekick's agent tools can reason about all of them simultaneously.

Debug sessions — debug sessions are tied to a specific binary view. You can run simultaneous debug sessions for multiple binaries in a project, but each session is associated with exactly one binary view.

Cross-binary analysis

When all project binaries are open, Sidekick's analysis tools operate over the full set.

BNQL queries automatically span all open binaries. A query like /view/function[@name ~= r"crypt"] will search every open binary in the workspace and return matches from all of them. Results include the binary view they came from, so you can tell which binary each match belongs to.

Semantic search uses the cross-binary index. When you use concept("authentication") in a query, Sidekick searches the embedding index for all open views and surfaces the most relevant functions regardless of which binary they are in.

The AI agent has access to all open binaries when processing a request. If you ask "which binary exports a function that calls EVP_EncryptInit?", the agent can query all open binaries to find the answer. When multiple binaries are open, you can mention a specific filename in your message to direct the agent's attention to it.

Opening and closing individual binaries

Binary Ninja projects allow you to open and close individual files independently. Sidekick tracks these lifecycle events:

  • When you open a binary, Sidekick registers it with the workspace and its semantic index scope becomes active. The binary profile notebook entry is created or reactivated.
  • When you close a binary, its semantic index scope is deactivated and the binary profile notebook entry is updated to reflect the closed state. The rest of the workspace data (chat history, indexes, etc.) is retained.

You do not need all project binaries open at once. Sidekick works with whatever subset is currently open, and data accumulated when other binaries were open is preserved in the workspace for future sessions.

Switching between binaries

The Sidekick Chat, Notebook, and Indexes sidebars maintain a single panel for the entire workspace. Your chat history, notebook, and indexes remain visible as you switch between binary view tabs.

The Transaction Log sidebar is scoped to the active binary view. It shows only the transactions for whichever binary is currently focused in the editor.

Managing workspace data

You can view and manage workspace data for all your projects and standalone files from Plugins > Sidekick > Manage Workspaces.... Each row in the list represents one workspace:

  • Project-backed workspaces show the project name.
  • File-backed workspaces show the filename.
  • Hover a row to see the full path and the workspace ID. This is the easiest way to distinguish copied standalone workspaces created by File > Save As.
  • Open workspaces are shown in green and cannot be deleted while open. Close the project or file first, then return to this dialog to clean up workspace data.

Warning

Deleting a workspace permanently removes all of its chat history, indexes, and semantic embedding data. This action cannot be undone.

To move or share workspace data from a multi-binary project, use the export/import workflow described in Sharing Analysis Data.

Tips for multi-binary projects

  • Open all related binaries before starting analysis. Sidekick can only query binaries that are currently open. If you want cross-binary search results, open all relevant files before asking Sidekick questions.

  • Use the Notebook to track binary-specific findings. When Sidekick discovers something significant in one binary, you can ask it to add a notebook entry. Because the Notebook is project-scoped, that entry is visible when you later switch to a different binary in the same project.

  • Reference binary names in chat. When your project has multiple binaries, mention the specific binary file you want to analyze in your message. This helps Sidekick direct its queries to the right view.

  • Build per-binary indexes when needed. If you want focused search over a single binary, create a named index and populate it from that binary's functions. You can build separate indexes for each binary and query them independently.

  • Save your project after analysis. Project-backed workspaces use stable IDs, so your chat history and analysis data are reliably associated with the project across sessions.