ida-tui.git/ida-tui, branch main

Switch to ida-nexus

2026-08-20T21:55:52Z

Rebase MISTER EXO's ida-codemode port onto the current tree

2026-08-07T10:40:14Z

Mechanical part of the port: the 27-file patch was cut against a base ~148 commits behind us, so it did not apply. Resolved 11 conflicts (all of them diff drift, not semantic clashes) and the three file deletions: - app.py: the patch re-inserted _do_rename/_do_name_addr/_seek_split etc. as "theirs" because our tree moved them to edit_ctl.py/trace_ctl.py. Kept ours and applied the real intent (WorkerClient->CodeModeClient, .call->.invoke, _open_worker_client->_open_database_client) at their current homes. - domain.py: kept Head as a NamedTuple -- the patch reverted it to a frozen dataclass, which the perf work measured at 2.9us vs 1.9us per row on a quarter-million-row walk. Dropped _fetch_output (no download_url under Code Mode) and its now-dead urllib/json imports. - pane.py: the patch's deletion swallowed our zellij support along with the worker-reaping block it meant to remove. Kept zellij, removed the reaping. - test_scenarios.py: the idb_save->save_database teardown hunk belongs to tests/_fixtures.py in our tree; applied it there and kept our pc_num_format scenario that the drift landed on. Three defects in the patch itself, fixed here: - It made "import idatui" hard-require ida_codemode, so every offline suite died at import -- including the pure ones (graph/index/trace) that are the house rule for "tests/run.py --fast". The import is now deferred and gated on the binding, which is also what lets the port's own contract tests inject a fake DatabaseHandle. - project.stage() inlined an ida_codemode.registry import and treated "library not installed" as "someone owns this database", which broke IDA-free project staging. Ownership lookup moved to codemode_client.database_owner(). - tests/test_codemode_client.py had no NEEDS_IDA marker, which tests/run.py rejects outright. Offline suite: 301 passed, 0 failed. Against master's 344 the whole delta is accounted for: -40 worker_client (module deleted), -18 launch sweep checks (behaviour deliberately removed) +3 guarding that it stays removed, +2 pool (GUI-save semantics), +13 new codemode_client contract tests. NOT yet done, and the port is not functional without it: the adapter is missing five operations our tree grew since the patch's base (flowchart, op_format, pc_nums, pc_num_format, survey_binary) and its "heads" predates back-walking and digest/expect.

mcp: delete the ida-pro-mcp transport, supervisor, and mcp-only tests

2026-07-24T12:53:56Z

The idalib worker is the only backend now, so remove the dead HTTP/supervisor surface entirely (~2200 lines): * deleted idatui/client.py (the IDAClient HTTP/JSON-RPC transport + session manager), idatui/tui.py (the old mcp TUI entry, superseded by launch.py), spawn.sh, and systemd/ (the supervisor unit). * deleted the mcp-only tests (stress_client, smoke_client, test_keepalive, stress_paging, rpc_smoke, serverctl.sh, pane_smoke, test_domain) -- the worker pilot (tests/test_scenarios.py) supersedes them. * migrated the tmux RPC harness (idatui/pane.py) to the worker: it spawns `idatui.launch --rpc ` instead of the mcp `idatui.tui`, drops the supervisor auto-start/ensure machinery, and reaps our own worker (idatui/worker.py) instead of ida_pro_mcp.idalib_server. --db/--url/--no- ensure-server are gone; --open is required. * __init__ / __main__ / domain no longer import client (exceptions come from errors.py, the domain client hint is WorkerClient); pyproject points both console scripts at idatui.launch; README + ida-tui header describe the worker-only flow. What stays (by design): the ida_pro_mcp *package* (the worker reuses its @tool functions in-process) and server/patch_server.py (the worker injects its custom tools on startup). Verified: whole package imports + IdaTui constructs + pilot lists 31 scenarios. The worker pilot (134 pass / 2 known flakes) is the E2E gate.

deprecate: make the idalib worker the default backend; mark mcp path for removal

2026-07-23T23:56:47Z

Opening a binary now defaults to our own idalib worker; the ida-pro-mcp HTTP supervisor path is deprecated (kept only for --db/attach and --backend mcp). * launch.py: --backend default resolves to worker for a fresh binary open, mcp for the attach modes (--db / bare `ida-tui`, which have no worker equivalent); explicit --backend or IDATUI_BACKEND still wins. Logs a deprecation notice when the mcp path is used. * Deprecation markers on client.py and server/patch_server.py; the ida-tui shell header and README now describe the worker as primary and note $IDATUI_WORKER_PYTHON. TODO tracks the removal checklist. No code deleted yet — the mcp fallback stays until the worker is proven on a box where idalib can spawn (pilot against --backend worker is the gate). Backend resolution matrix verified: `ida-tui bash`->worker, bare/`--db`->mcp, explicit flag/env honored.

launch: `ida-tui foo.elf` one-shot wrapper (server + locks + session)

2026-07-22T22:14:59Z

A caveman entry point so you don't hand-craft the plumbing every time. It: * ensures the ida-pro-mcp supervisor is up — starts spawn.sh detached (start_new_session, tmux-free) and waits for the port if it's down; * recovers a binary wedged by a hard-killed worker — sweeps the stale unpacked .id0/.id1/.id2/.nam/.til next to the .i64 and retries (the packed .i64 is never touched); * adopts an already-open session for the same binary (idempotent), else idb_opens it with a sane idle-TTL; * launches the TUI attached to that session with keepalive on. ./ida-tui /path/to/binary # open a binary and drive it ./ida-tui # attach to the sole session ./ida-tui --db # attach to a specific session Pieces: idatui/launch.py (logic, reuses pane.py's server probe), a repo-root `ida-tui` sh wrapper (resolves ~/ida-venv python, keeps idatui importable from any cwd), and an `ida-tui` console-script in pyproject. --help works without textual (app imported late). README documents both the one-liner and the manual recovery. gitignore bin/ (binary targets, like targets/). Verified live: ensure_server up-detection, open, adopt (same session id), and lock-sweep all work against a running supervisor.