Skip to content
heyaican

Released Apr 2026

Record sheet · No. 065

REA

A local MCP server and command line that turn decompilers, a JavaScript and .NET reader, a browser and a process recorder into one set of tools an agent can call, and return every finding with the evidence and the limits attached to it.

Open it Source Submit a correction
Screenshot of REA
Editor screenshot, 11 Oct 2026REA ↗

What it is

REA is a reverse-engineering command line and MCP server that opens a shipped program in Hopper, Ghidra or IDA and returns pseudocode, assembly and cross-references.

It is a local MCP server and command line that an agent calls one tool at a time, and each call returns what it found with the evidence behind it. Open a native binary through the Hopper, Ghidra or IDA installation you already have and read pseudocode, assembly, strings, cross-references and call graphs.

Unpack a JavaScript or Electron application and follow it down to its IPC boundaries. Read a .NET assembly's metadata and CIL without executing it.

Drive a Chrome-family browser over a page and record what it requested. Record a process's terminal output, exit status and filesystem effects.

Unpack firmware, decode an Android package, or read a saved HAR. Analysis runs on the machine that holds the target: the project's rule is local-only, and nothing leaves except what the agent's own model provider receives.

Where a tool cannot see something, the result says so as an unknown instead of filling the gap. Decompilation itself is not in the package, and neither is an installer: the release page carries no files.

Who built it

One GitHub account, created on 2020-12-22, with 252 public repositories and 1,549 followers. Its bio reads member of technically staff and it lists Sinsai as its location. The contributor table names 92 accounts. Three do most of the work outside the owner: @N0zoM1z0 with 445 commits, @kaoru0822-kitauji with 373 and @rudycelekli with 85, against the owner's 1,214. The two showcases the README links are that first account's own repositories, N0zoM1z0/dx-ball and N0zoM1z0/th04.

How it is put together

The parts · 6

The organising idea is that the analysis is a pipeline of declared contracts and the agent is only a client of it. Every capability is a tool with a named input schema, a named output schema and an audited effect record, and the same inventory backs the MCP server, the command line and the generated documentation, which is what lets CATALOG_IDENTITY publish a sha256 over the whole surface and a verifier compare a published package against the source revision it claims to be. Around that sit four layers with one direction of dependency: domain semantics and contracts at the centre, then provider adapters, then shared application workflows, then the CLI and MCP adapters on the outside, which AGENTS.md states as a rule and .github/workflows/ci.yml enforces through a module-boundary check. Providers are not bundled. Each one is a bridge REA writes to somebody else's scripting surface, Hopper through its Python API, Ghidra through a headless Java script, IDA and JEB through MCP servers the caller already has running, which keeps REA from shipping a decompiler while still giving the agent decompiler results. Nothing is uploaded and nothing is mutated: native analysis runs against ephemeral Ghidra databases or a read-only IDA attachment, annotations land in the session rather than the executable, and AGENTS.md forbids an installer from touching unrelated software.

src/contracts and src/server
The public surface: 172 tool contracts with named schemas and effect audits, the prompt contracts beside them, schema profiles for clients with smaller budgets, and the MCP server that registers all of it and returns results in one canonical encoding.
src/domain
458 files and roughly 100,000 lines of semantics: the Evidence record and its bundles, the tagged error algebra, the analysis view and profile, call paths, function comparison, reconstruction coverage and its obligation ledger, dyld resolution, and the JavaScript semantic graph and static analysis.
src/hopper, src/ghidra, src/ida, src/jeb and bridge/
Four provider adapters and the scripts they drive. Hopper over a socket to a Python bridge loaded inside the application, with a target lease and a cancellable regex worker; Ghidra headless through AnalyzeHeadless with REA Java scripts; IDA and JEB through MCP servers the caller starts.
src/dotnet, src/native, src/artifacts and src/javascript
The readers that need no engine: a managed-assembly parser covering the metadata heaps, table layout and CIL, Mach-O and PE resource inspection, plists, keyed archives, code signatures, Apple bundle anatomy, package formats, source-map decoding and JavaScript source recovery.
src/browser, src/process, src/inspector, src/adb and native/windows
The half that watches things run: DevTools-protocol browsing and scenario capture, process ownership and capture, Node Inspector targets, Android device control over adb, and the C++ Node-API addon that gives Windows handle-based filesystem authority, Job Object ownership and private DACLs.
src/cli, install.sh, .agents/skills and .github/workflows
The way in: one-shot commands that mirror the tools, a setup step that edits client configuration with a plan and a backup, the bundled reverse-engineer-anything skill and its reference files, and 22 workflows of which most are named Real … because they run against a real engine rather than a fixture.

Choices, and the alternative

  • Drive engines the user already has instead of bundling a decompiler over shipping an analysis engine of its own

    third_party/README.md states the policy and the reason together: upstream source stays unmodified in a pinned submodule, is never copied into REA's domain or application code, and no engine is downloaded during an analysis. What REA keeps is the bridge, the contract and the interpretation, which is why the Ghidra bridge is 3,833 lines of Java in this repository rather than a dependency.

  • Audit every tool's effects and derive its MCP annotations from that audit over deciding read-only and destructive hints per tool by hand

    toolEffects.ts carries a declared effect record for all 172 tools, annotationsFromEffects derives the four MCP hints from those eight booleans with no tool-name heuristics, and toolContractMetadata throws if a tool has no entry. A new tool cannot ship without somebody stating what it does to the target, the session, the filesystem and the network.

  • Keep the agent-facing surface and the human-facing surface the same inventory over a CLI with its own convenience commands

    The CLI names are a frozen object in src/cliCommandNames.ts, the tool contracts are one ordered array, and catalogIdentity.ts digests all three catalogues together. That is what makes the verification lanes meaningful: a published package can be asked whether its tool list is the canonical one.

  • Refuse to let setup install or upgrade anything it did not have to over a setup step that gets a working toolchain in one go

    AGENTS.md writes the rule out for installers, naming Homebrew, Node.js, npm, Java and Ghidra as things that must not be touched, and requires rea setup to show its plan and get approval before writing files. Hopper is the single exception, and even there it is offered rather than taken.

  • Analyse on the caller's machine and upload nothing over a hosted analysis service

    The repository describes itself as a local-only tool, targets are read from local paths, engines are launched as child processes, and the README answers the upload question by pointing at the agent's own model provider for the data policy. It is the reason a target can be something the user is not allowed to send anywhere.

Read fromREADME.md, AGENTS.md, CONTRIBUTING.md, SECURITY.md, package.json, server.json, .gitmodules, third_party/README.md, docs/installation.md, docs/testing.md, docs/mcp-contracts.md, docs/windows-ghidra-p0.md, docs/roadmap.md, docs/architecture.mermaid, vitest.config.ts, .github/workflows/ci.yml and the rest of .github/workflows/, scripts/verify-deepseek-client.mjs, src/catalogIdentity.ts, src/contracts/, src/domain/, src/native/, src/dotnet/, src/hopper/, src/ghidra/, bridge/, native/windows/ and .agents/skills/ in morluto/rea, read 2026-10-11.

Build log

7 stages
  1. 01

    What the thirty megabytes are

    I cloned main on 2026-10-11 at 14:58Z and measured the tree rather than the repository page. It holds 2,779 files and 31,123,835 bytes, which is 29.7 MiB. GitHub's own size field says 46,708 KB, because that counts what the packfile stores. The language breakdown agrees with the tree to within rounding: 14,136,292 bytes of TypeScript, 1,714,588 of JavaScript, 521,528 of HTML, 292,270 of Python, 274,198 of Java, 69,042 of C++ and 4,208 bytes of assembly. Counting source rather than data, 2,467 files hold 497,077 lines. The mass is in src/: 1,497 TypeScript files carry 300,089 lines, and 340 of them are tests living inside the source tree at 77,189 lines, which leaves 222,900 lines of non-test TypeScript. src/domain alone is 458 files and 100,001 lines. tests/ adds 578 files and 127,061 lines, scripts/ 241 .mjs files and 48,664 lines, and docs/ 47 markdown files and 10,460 lines. Across src/ and tests/ there are 4,463 it( blocks in 742 files, over the twelve vitest projects named in vitest.config.ts. The largest single source file is not a table: src/adb/AdbProvider.ts is 2,070 lines, and behind it sit src/domain/native/nativeAotPe.ts at 1,798, a process-capture lifecycle file at 1,531, a client-configuration document at 1,459 and two JavaScript semantic-analysis files at 1,220 and 1,119. The rest is not code. website/locales/ holds 18 gettext catalogues, for ar, de, es, fa, fr, id, it, ja, ko, pl, pt-BR, ru, th, tr, uk, vi, zh-CN and zh-TW. Together they are 237,154 lines and 9,094 KB, and one file runs from 471,205 bytes of Chinese to 619,905 of Thai. Eighteen translated READMEs sit beside the English one. Four bridges are written in other languages: bridge/ghidra/ReaGhidraBridge.java alone is 3,833 lines and 185,179 bytes, the Ghidra scripts total 4,879 Java lines, bridge/hopper_bridge.py is 1,162 lines of Python, bridge/native/rea_lldb_tracer.py is 839, and native/windows/src is 1,326 lines of C++ compiled into one prebuilt Windows addon.

  2. 02

    One server, 172 tools, and what sits behind each of them

    The public inventory is one ordered array. src/contracts/toolContracts.ts spreads 25 files into TOOL_CONTRACTS, and every contract is built through a helper that calls toolContractMetadata(name), which throws Missing effect audit for <name> when src/contracts/toolEffects.ts has no entry. That file is the audit, so its keys are the tool list: 172 names, from open_binary, list_procedures and procedure_pseudo_code, through analyze_javascript_application, inspect_managed_artifact, observe_web_execution, capture_process_scenario, extract_firmware and pull_adb_package, to verify_reconstruction and build_reconstruction_obligation_ledger. Parsing the 28 contract arrays directly gives 170 names, and read_bytes and address_to_file_offset live in a separate file, so the two counts meet at 172. src/catalogIdentity.ts publishes the same number as CATALOG_IDENTITY.counts.mcp_tools, beside a CLI-command count and three sha256 digests over the tool catalog, the prompt catalog and the two together. What sits behind a name varies by name. For native work REA holds no decompiler; it holds bridges to three. Hopper is driven by bridge/hopper_bridge.py, which REA loads inside the running application, and src/hopper/ is a client for it: a request queue, a target lease, a cancellable regex worker, cleanup, and a 1,026-line HopperClient.ts. Ghidra is launched headless through ghidra.app.util.headless.AnalyzeHeadless with REA's own scripts passed as -scriptPath and -postScript, among them ReaGhidraBridge.java, ReaGhidraPrepareCom.java, ReaGhidraApplySeeds.java and ReaGhidraNoReturnFix.java. IDA is reached through an IDA MCP server the caller starts, JEB through a JEB client the caller starts, JADX through a headless MCP JAR the caller supplies, and firmware through Binwalk or Unblob. Other names are REA's own readers. src/dotnet is 28 files and 9,278 lines that parse a managed assembly without running it: a PE reader, the metadata heaps, table layout and row sizes, a CIL instruction decoder, a method-body reader, and validation of exception regions. src/native is 54 files and 11,982 lines of Mach-O inspection, PE resource parsing, plists and keyed archives, code-signature reading, fat-binary selection, dyld resolution and an LLDB call tracer. src/browser is 113 files and 24,424 lines over the DevTools protocol, src/process is 57 files and 13,917 lines of process ownership and capture, and the JavaScript side carries its own parser, semantic graph and source-map decoder instead of calling an external analyser. third_party/README.md states the arrangement in one paragraph: REA integrates existing tools through provider adapters, upstream source stays unmodified in a pinned submodule, and it is not copied into REA's domain or application code. Five submodules are pinned by commit, JADX headless MCP, Binwalk, Unblob, a NativeAOT Ghidra extension and Wakaru. REA does not download an engine while an analysis is running.

  3. 03

    How far "reverse engineer anything" can be checked

    The claim is the repository description: Reverse engineer anything with agents, from app behavior down to native binaries. The README's capability table is where it can be checked, because its last column says what each target needs. It has 15 rows. Two need nothing beyond Node: JavaScript and Electron applications, and .NET assemblies, whose requirement column reads None (static only). Two more need software a reader likely has: a Chrome-family browser for websites, and a HAR for saved captures. The other eleven name an engine or an operating system. Hopper, Ghidra or IDA for native binaries. Caller-supplied pwntools on Linux x64 for offline ELF layout. WABT 1.0.42 for WASM artifacts. A raw carrier on Linux x64 for EVM bytecode. pwntools plus optional GDB and pwndbg for recorded Linux crashes. Headless JADX and a full JDK for Android packages, adb for Android devices, Apktool for Android resources. Binwalk or Unblob on Linux for firmware. A caller-started JEB client for JEB projects. A native PTY on Linux or macOS for process behaviour. The Windows boundary is written down instead of discovered. docs/windows-ghidra-p0.md calls its Windows x64 support experimental and read-only, names 25 read-only Ghidra inventory, memory and function operations as what is available, and says in its own words that the boundary does not establish general Windows feature parity. Native 32-bit x86 PE support is on main and not in npm releases through 5.0.0. Ghidra GUI state, annotations, other architectures and formats, and every Hopper-only operation are out of scope there. Hopper itself is an application REA drives on macOS and Linux, which is why the project keeps a separate Linux lane and a private-display probe for it. Whether the analysis is real is a different question from whether it travels, and on that one the tree is specific. The .NET reader decodes CIL itself and validates exception regions. The Mach-O side predicts dylib load order and checks that prediction against the images dyld actually loads. The JavaScript side builds a semantic graph with member mutations, promise ownership and reference lifetimes, and inspects source maps in the same process. src/domain/native/nativeAotPe.ts parses NativeAOT ready-to-run snapshots out of a read-only image. What is not in the tree is a disassembler, a decompiler or an emulator. The README's own closing note is the shape of the whole thing: REA provides tools for lawful reverse-engineering research, and the deep native lane is somebody else's engine driven through a contract REA maintains.

  4. 04

    DeepSeek Harness: documented, verified on POSIX, not supported by setup

    A reader of this site has a direct stake in this part. DeepSeek Harness is not in REA's client table. That table lists 17 clients rea setup --client can configure: Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, Antigravity, GitHub Copilot CLI, Command Code, Qwen Code, VS Code, Grok Build, OMP, Pi and Hermes, with Grok Bot after the table because its connector is not one of those files. Harness has its own section below, under a heading that says what the difference is: it uses a Cordis YAML patch sequence instead of an mcpServers object, and setup --client does not edit that format. What the documentation gives instead is a hand-written patch for Harness 0.2.0-rc.2. Append an entry with id: rea-mcp, name: "@deepseek-ai/dsh-mcp-client", serverName: rea, transport: stdio, and absolute paths to node and scripts/rea.mjs, to $DSH_HOME/cordis.patch.yml, or ~/.dsh/cordis.patch.yml when DSH_HOME is unset. Harness then exposes the tools as mcp__rea__<tool_name>. The bundled skill is a second step, rea setup --skill, which installs into ~/.agents/skills; Harness discovers that directory on its own, or under $DSH_AGENTS_HOME/skills when configured, and its native skill tool can then load reverse-engineer-anything. There is a verification lane for the integration and it is narrow. npm run verify:deepseek-client runs scripts/verify-deepseek-client.mjs, which requires an installed dsh, verified against @deepseek-ai/dsh@0.2.0-rc.2, writes the Cordis patch into an isolated DSH_HOME, and binds HOME and USERPROFILE to a disposable account. It checks skill loading, complete catalog discovery, the forwarded input schemas and regexes, and one full JavaScript Evidence result for a path containing a non-ASCII character. Its ninth line asserts that the platform is not Windows, with the message Native Windows coverage is unverified. The model behind it is a local OpenAI-compatible fixture that declares the one-million-token context of Harness's default DeepSeek Flash model, so the lane establishes the integration and not live DeepSeek API compatibility; docs/testing.md says so in as many words. The lane is POSIX-only, and no workflow under .github/workflows/ invokes it, so it runs when somebody runs it. The gap is on the tracker with a proposal attached. Issue #1839, [Feature] Add native DeepSeek Harness (DSH) client support to REA setup, was filed on 2026-10-11, carries the labels enhancement and triage, and had no comments when I read it. Its body is specific about what is missing: rea setup --client dsh --dry-run --json, rea doctor --client dsh --json, idempotent registration, safe removal, and preservation of unrelated Cordis content, with the author offering to implement it and asking the maintainer how Cordis YAML should be handled safely. That question is the one still open. A second issue the day before, #1636, asks how to track a headless Harness run that finishes without the process exiting.

  5. 05

    Six months of history, and most of it in the last week

    GitHub created the repository on 2026-04-14 and the first commit landed the same minute, at 2026-04-14T00:51:30Z. Then nothing until 2026-07-11. main now carries 2,323 commits, the last of them at 2026-10-11T14:58:01Z. By month that is one commit in April, 697 in July, 21 in August, 100 in September and 1,504 in October. By week it is sharper. 110 in the week of 2026-07-06, 364 the next, then 172, 56, 11, 4, and single commits through most of August and September, then 107 in the week of 2026-09-28 and 1,496 in the seven days ending 2026-10-11. Close to two thirds of the project's entire history was written in its last week, and the October daily counts behind it read 117, 113, 281, 205, 351, 268 and 161. The subjects say what kind of work that is. 1,005 of the 2,323 commits begin with fix, against 200 test, 187 feat, 181 docs, 164 refactor and 105 perf. 103 author names appear; by GitHub account the counts are 1,214 for morluto, 445 for N0zoM1z0, 373 for kaoru0822-kitauji and 85 for rudycelekli, and the contributors endpoint returns 92 accounts. 380 commits carry a Co-authored-by trailer, and of the 489 trailer lines, 297 name a model or an agent: Claude Opus 5.5 in 260, Cursor Agent in 23, Devin in 5 and Claude Sonnet 5.5 in 3. Seventy-eight commits carry Signed-off-by. A page of the branch list is mostly agent branches, agent/…, codex/…, cursor/…, alongside release/… and fix/…. The releases are steady and empty. 35 of them run from rea-0.2.0 on 2026-07-12 to rea-agents-6.4.0 on 2026-10-11, and every one carries 0 attached files, because the distribution is npm. npm holds 31 published versions of rea-agents, and 6.4.0 unpacks to 7,776,450 bytes. Downloads have the same shape as the commits: 10 to 43 a day through September, then 418 on 2026-10-03, 798 the next day, 4,048, 5,032, 9,000, 19,983 and 34,790. That last week is 73,651 of the 74,461 downloads in the whole month. Two lines in the README belong to the same fact: the star section now reads 90,000 GitHub stars, and the disclaimer below it says the project has issued no cryptocurrency or token and that tokens using the REA name are not affiliated with it. The figure moves faster than a record can hold it. The API returned 91,053 stars at 22:52 on 2026-10-11, and the monitoring baseline this archive wrote at 23:07 the same evening read 91,384.

  6. 06

    A hundred and fifty-nine open items

    GitHub's counter read 159 open items on 2026-10-11. Paging the issues endpoint the same evening returns 107 issues and 50 pull requests, and the pull-request endpoint on its own says 51, so the number is mostly issues plus open work from contributors. Only 15 of the 107 carry the bug label, against 71 enhancement, and 45 still carry triage, the label for what the maintainer has not read yet. The other frequent labels are P1: high at 36, roadmap at 22, area: mcp at 18, P2: medium at 16, area: providers at 12, area: domain at 11 and P0: critical at 10. Nineteen carry no label at all. 53 of the 107 have no comments, and 66 were filed in the seven days before this record. Eleven are more than three months old and twenty-seven fall between one and three months. The oldest ten were all filed on 2026-07-12, the day after the first release, and they are the epics: #32, Roadmap: evolve REA into an agent-first multi-tool reverse-engineering platform; #39 for browser and web support; #48, Epic: Evidence v2 and deterministic process fidelity; and #54, #55 and #59 on Hopper function dossiers and process-tree capture. A second epic cluster from the same fortnight covers Hopper conformance verifiers, #333 and #339 through #344. The largest single cluster is Windows, and it is one epic filed as sixteen issues. #287 to #290 and #318 to #329 all date from 2026-07-16 and 2026-07-20, and all describe the same native Node-API package: handle-based reparse-safe filesystem authority, Job Object ownership with kill-on-close, private DACLs on runtime roots, and a real-Windows verifier for each. They are still open. The next cluster asks for provider lanes instead of fixes: MIPS16 (#1851), armhf (#1745), PowerPC (#1741), 6502 and 65816 (#1641), MIPS32 (#1620), PSP (#1330), AArch64 jump tables (#487), dSYM matching (#1193) and NativeAOT (#744), plus three that want a different engine entirely, Binary Ninja (#1551), the official Hex-Rays IDA MCP server (#1416) and rsleigh (#1389). Client onboarding is its own small group: DeepSeek Harness (#1839), Kimi Code (#1791), a Codex plugin (#1269) and an install that needs no package manager (#1316). The bugs are the ones a user would meet. #1387 reports analyze-javascript-application --json aborting on a bundle that 6.2.0 completed, which makes it a regression in a version people had. #1554 reports that the full MCP input catalog blocks ordinary chat in GitHub Copilot CLI. #1720 reports query calls dying at a flat 60-second timeout, shorter than the configured Ghidra startup deadline. #1719 reports open_binary returning without starting a provider client at all. #1701 reports the Windows native authority self-test failing on real Windows and leaving probe directories behind. #1808 reports Hopper 6.6.0 in demo mode segfaulting while analysing a system binary and leaving a poisoned session. #1859, filed the day this record was written, reports that the Windows real-Ghidra verifiers fail on every host. The items with the most discussion are the design ones and not the bugs: #1065 has 40 comments, #740 has 21, #287 has 15 and #724 has 11.

  7. 07

    It runs, and what it asks you to install first

    Installation is one command. npx rea-agents setup registers the MCP server with the clients you pick and installs the matching skill; npm install --global rea-agents gets a rea binary for the terminal; install.sh in the repository exits unless the platform is Darwin or Linux. Node is the hard requirement, at 22.x from 22.19, 24.x from 24.11, or 26 and later. I pulled the published package rather than describing it. rea-agents@6.4.0 is 1,825,761 bytes compressed and 7,776,450 bytes unpacked, with 1,161 entries: 1,112 of them JavaScript under dist/, 7 the bundled skill, 21 the bridges, and one the prebuilt Windows x64 Node-API addon at native/windows/build/rea-windows-x64.node. The Ghidra Java scripts and the Hopper Python bridge ship inside the npm package, so nobody assembles a bridge by hand. 35 runtime dependencies come with it. rea setup shows a plan and requires approval before it writes, backs up whatever it edits, and will not install or upgrade Ghidra, Java, Python, Node, npm, Hopper or a compiler. Hopper is the one engine it can offer to install, and only with approval. Analysis is local, and the README's answer to whether REA uploads your application is that targets are analysed locally and the agent's model provider has its own data policy. Continuous integration is where the volume shows. Twenty-two workflows are registered, twenty-one active and one disabled by hand, and the API counts 13,777 runs across them. The main ci.yml has completed 2,500 times since 2026-09-01, and 800 of those completions fall inside the 25 hours before this record was written. Of the 800, 198 succeeded, 115 failed, 266 were cancelled by a newer commit, and 221 sat in action_required, which is GitHub holding a fork's workflows until a maintainer approves them. On main the cancellation is the rule: of 214 push runs, 182 were cancelled. Package lanes run on Linux x64, Linux arm64, macOS 15 on both architectures, and Windows x64. Two limits are written into the repository itself. Windows native analysis is the experimental, read-only boundary described above, and the DeepSeek Harness verification lane refuses to run on Windows at all. And a feature on main may not be in the npm release you installed; docs/installation.md keeps a Released package and main section for exactly that, naming 6.4.0 as the release it checked on 2026-10-11.

What they would tell you

  • There is no installer to download. All 35 releases carry zero attached files, and install.sh exits unless the platform is Darwin or Linux, so on Windows the path is npm plus the prebuilt x64 addon. Windows native analysis is described in docs/windows-ghidra-p0.md as experimental and read-only, limited to 25 Ghidra operations, with 32-bit x86 PE support on main and not in npm releases through 5.0.0.
  • The claim is bounded by what the reader already has. Two of the README's fifteen target rows need nothing but Node. Eleven name an engine, a device tool or a POSIX host, and the README says which in the same table that makes the claim, so "anything" here means anything whose format either has a reader in this repository or an engine on your disk.
  • The star count and the project's age are not the same measurement. 91,053 stars and 20,140 forks arrived in under six months, but the repository held a single commit for its first three months, 1,496 of its 2,323 commits landed in the final seven days, and 1,005 of the commits begin with fix. Major versions 4.0.0, 5.0.0 and 6.0.0 went out on 2026-10-05, 2026-10-07 and 2026-10-08, three days apart.
  • The open queue is young and mostly not bugs. 66 of the 107 open issues arrived in the last week and 53 have no comments at all. A sixteen-issue cluster describing one Windows native-authority package has been open since 2026-07-16 and 2026-07-20, and the Hopper dossier and conformance epics have been open since 2026-07-12, which is where the work that has not converged actually sits.
  • The CI passes less often than its volume suggests. 800 completed ci.yml runs in 25 hours, of which 198 succeeded, 266 were cancelled and 221 were waiting for a maintainer to approve a fork's workflows; on main, 182 of 214 push runs were cancelled by a later commit. A green check here is a statement about one commit at one moment, and the package lanes on five runners are the part of that matrix worth counting.
  • DeepSeek Harness is documented and not supported. rea setup --client covers 17 clients and Harness is not one of them, so the integration is a hand-written Cordis patch in the docs plus a separate skill install. The verification lane refuses to run on Windows, drives a local model fixture instead of the live API, and is invoked by no workflow. Issue #1839 asks for first-class support and had no reply when this record was written.
  • Four of the open bugs are about the shape of an answer rather than the analysis inside it. #1719 reports open_binary returning without starting a provider client, #1720 reports query calls dying at a 60-second ceiling, #1387 reports a newer minor version aborting on a bundle the previous one finished, and #1808 reports a demo-mode Hopper segfault leaving a poisoned session behind. In each of them the tool answered, and the answer was not what the contract said it would be.

Adjacent records

All records →

No. 135

OKF Agent Memory

Keeps what a coding agent learns as plain Markdown inside the repository (an OKF v0.2 knowledge bundle searched in-process by BM25) so the memory can be diffed and reviewed instead of living in a database.

No. 117

Whiteboard

A desktop app that puts an agent and a person on the same canvas: the agent draws the review (sequence diagrams, entity relationships, code peeks pinned to specific commits) and every shape on that canvas links back to the code it was drawn from.

No. 107

OpenMausBot

An open-source chat app where every bot in the sidebar is a real agent running through the CLI already installed on your machine, and each one can be handed a computer: a cloud Linux desktop, a Docker or Podman container on the same host, a container on a VPS you own, or the machine in front of you where the platform can show that it is safe.