OpenResearch - Moses Yebei

The Problem

Researchers often juggle multiple code‑review, experiment, and artifact‑management tasks on a single machine. Existing tools separate code, data, and experiment logs, making it hard to tie a specific run to the exact code and model used. The result is duplicated effort, hard‑to‑reproduce experiments, and a fragmented user experience.

What This Does

OpenResearch turns any LLM harness (Claude Code, Codex, OpenCode, Cursor) into a research agent that can independently explore a hypothesis, launch an experiment, and store evidence in the same Git‑native workspace. The CLI (src/commands/*.rs) orchestrates everything from orx up to orx run. The server (ui/src/App.tsx and ui/dist/index.html) provides a local dashboard that surfaces logs, diffs, and artifacts. agent-skills/ bundles reusable agent behaviours (e.g., orx-compute, orx-create, orx-experiment-tree) that can be invoked via the CLI or the UI.

How It Is Wired

Entry Point – src/main.rs parses CLI args and dispatches to the appropriate command module. Command Layer – src/commands/compute.rs → src/jobs/* (e.g., src/jobs/localbox.rs, src/jobs/k8s.rs) and src/compute.rs to launch compute jobs. Agent Layer – src/local/agent_skills.rs loads skill definitions from agent-skills/. Each skill exposes a run(ctx) function that the CLI calls. State Layer – src/config.rs reads Cargo.toml, ui/package.json, and demo/nanochat/base/pyproject.toml for default settings. Project state lives in the workspace’s .orx/ directory; all commits are recorded in Git. UI Layer – ui/src/App.tsx fetches state via a REST endpoint served by src/commands/serve.rs. The UI does not mutate state directly; it only visualises the Git tree and logs.

The breadth of the effect is limited: src/main.rs is the single entry point, src/commands/*.rs are thin wrappers, and the core logic resides in src/jobs/* and src/local/agent_skills.rs. The only cyclic dependency is between agent_skills and commands, which is resolved at load time and does not affect runtime performance.

How To Use It

Setup

# clone
git clone https://github.com/moses-y/OpenResearch
cd OpenResearch
# install Rust toolchain
curl https://sh.rustup.rs -sSf | sh
# build CLI
cargo build --release
# install UI dependencies
cd ui
pnpm install

Configuration

src/config.rs reads CARGO_HOME and ORX_HOME (default ~/.orx).
To point a skill at a local model, edit src/local/agent_skills.rs or set ORX_MODEL_ENDPOINT in the environment.

Running

# start the dashboard
./target/release/orx up
# launch an experiment
./target/release/orx experiment run my_experiment

The dashboard is accessible at http://127.0.0.1:4791.

Real‑World Use

A research group can spin up a new experiment with orx experiment create, commit the experiment tree, and let the chosen LLM (e.g., OpenCode) generate a hypothesis. The LLM then runs orx compute on a local GPU cluster; logs and artifacts are stored under .orx/experiments/<id>/. The group can later replay the run with orx experiment replay <id>.

orx experiment create my_experiment
# LLM writes code
orx compute
# view results
orx experiment logs my_experiment

Code Health & Issues

Tests: 33 files in demo/nanochat/base/tests/ cover core engine logic.
CI: GitHub Actions (.github/workflows/*) run cargo test, pnpm test, and lint checks.
License: MIT, present in LICENSE.
No structural red flags: Cargo dependencies are locked, Rust code passes Clippy, TypeScript passes ESLint.
Missing docs: Several modules lack inline documentation; only top‑level README covers usage.

The Bottom Line

OpenResearch offers a unified, local‑first platform for research agents with a clear separation of concerns: CLI, compute, and UI. The architecture is modular, with a single entry point and minimal cross‑module coupling, making it straightforward to add new skills or compute backends. It is well‑tested and CI‑protected, though documentation could be expanded. Researchers who need reproducible, isolated experiments on their own hardware will benefit most.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

501 files

Rust110
TSX87
TypeScript46
Markdown38
Python38
JSON10

ReactPyTorchTransformers

Module dependencies

The 10 most depended-upon modules of 204, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_ui_src_api["api"] n1_ui_src_components_ui_index["index"] n2_ui_src_i18n["i18n"] n3_ui_src_queries_client["client"] n4_ui_src_queries_settings["settings"] n5_ui_src_components_ui_cn["cn"] n6_ui_src_tabPreview["tabPreview"] n7_ui_src_queries_projects["projects"] n8_ui_src_workspaceState["workspaceState"] n9_ui_src_queries_files["files"] n0_ui_src_api --> n3_ui_src_queries_client n0_ui_src_api --> n8_ui_src_workspaceState n0_ui_src_api --> n2_ui_src_i18n n9_ui_src_queries_files --> n0_ui_src_api n9_ui_src_queries_files --> n3_ui_src_queries_client n7_ui_src_queries_projects --> n0_ui_src_api n7_ui_src_queries_projects --> n3_ui_src_queries_client n4_ui_src_queries_settings --> n0_ui_src_api n4_ui_src_queries_settings --> n3_ui_src_queries_client classDef cyc stroke:#ef4444,stroke-width:2px; class n0_ui_src_api cyc;

Dependencies

6 of 72 declared dependencies are a major version behind. Resolved 41 of 72 against the registry.

Package	Declared	Latest	Behind
`pyarrow`	>=21.0.0	25.0.1	4 major
`@vitejs/plugin-react`	^4.5.0	6.0.5	2 major
`typescript`	^5.8.3	7.0.2	2 major
`vite`	^6.3.5	8.2.1	2 major
`numpy`	>=1.26.0	2.5.2	1 major
`@xterm/xterm`	^5.5.0	6.0.0	1 major

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical2

high2

medium4

low1

Do not check out pull request code in a privileged workflowcritical

.github/workflows/release-macos-app.yml

privileged trigger checks out the untrusted ref

This is the most reliably exploited Actions pattern: anyone opening a pull request gets code execution with your repository secrets.

Fix: Split into an unprivileged pull_request build and a workflow_run job that only consumes its artifact.

Keep secrets out of workflows a fork can triggercritical6 occurrences

.github/workflows/release-macos-app.yml

MACOS_CERT_P12_BASE64, MACOS_CERT_PASSWORD, MACOS_NOTARY_APPLE_ID, MACOS_NOTARY_TEAM_ID

Contributor-controlled input reaches a job holding a publish token or cloud credential, so a pull request becomes credential exfiltration.

Fix: Move secret-using steps into a workflow_run job that never checks out pull request code, or gate on an environment with required reviewers.

Pin third-party GitHub Actions to a commit SHAhigh3 occurrences

.github/workflows

pnpm/action-setup@v4, dtolnay/rust-toolchain@stable, Swatinem/rust-cache@v2

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Upgrade the pinned dependency carrying a published advisoryhigh14 occurrences

torch@2.9.1 CVE-2026-24747 (high) +3 more; tokio@1 CVE-2021-45710 (high) +7 more; zip@2 CVE-2025-29787 (high) +1 more

The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Enable Dependabot or Renovatemedium

3 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Remove generated build output from version controlmedium66 occurrences

66 generated files committed

The reviewer reads src, production runs dist, and a stale bundle means the fix that was reviewed is not the code that executes.

Fix: Gitignore the output directory and build in CI.

Set persist-credentials: false on checkoutmedium

.github/workflows/ci.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow3 occurrences

.github/workflows/ci.yml

3 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.