A successful package step did not produce a working simulation
Our MuJoCo Python run stopped with 25 collection/setup errors after installation and the build step succeeded. That distinction matters when choosing a simulator: the run provides setup evidence but cannot establish accuracy, speed or suitability for a particular robot.
MuJoCo is a physics engine for articulated structures interacting with their environment. The project README describes its C API and Python bindings. Researchers who want to control models and simulation state directly should consider evaluating those interfaces. This review did not reach a working physics workload.
What happened when we ran it
The sandbox targeted ./python/ at commit 371c2b4 on November 8, 2026. Installation succeeded in 20 seconds, with 35 dependencies recorded and 38 MB on disk. The build step succeeded in 1 second. Pytest exited 1 after 2 seconds with 0 passed, 0 failed and 25 collection/setup errors.
Zero failed tests does not mean the suite passed. Collection/setup errors prevented a passing result. The tail names thread-safety, USD, virtual-filesystem and viewer modules, among others; those names do not establish whether the corresponding features work.
The exposed ImportError reports missing or corrupted mujoco-core bindings. The log suggests reinstalling related packages, but it does not establish the cause or show a successful repair. A missing-core error is a finding about this setup, not evidence that the engine's physics is defective.
The recorded configuration was 3 CPUs, 8 GB RAM and image ghcr.io/astral-sh/uv:python3.12-bookworm. Actual runtime and operating-system versions remain unverified. The checkout contained 2,414 files, roughly 626,789 source lines and 118.1 MB. The recorded build step targeted the Python project; its 1-second duration is not a benchmark for compiling the entire native engine.
The run recorded 0 known vulnerabilities from pip-audit. That advisory result does not verify working bindings or simulation correctness. The repository scan found five CI workflows, a tests directory and no Dockerfile.
The 4.0.0 package split gives context, not a diagnosis
MuJoCo 4.0.0 separates core bindings from Studio and renderer bindings. The release notes, published November 6, 2026, identify mujoco-core, mujoco-studio and the default mujoco package that installs both.
The notes warn that upgrading a pre-split installation with pip can remove files moved to mujoco-core, and provide uninstall or force-reinstallation guidance. That guidance is relevant to the error message, but our log does not establish an upgrade history. No successful repair accompanies the measurement.
The release notes also direct readers to the latest Python documentation because documentation for the package split landed shortly after release. The supplied checkout was measured at commit 371c2b4; the record does not establish that the sandbox installed the published 4.0.0 distribution. Keep release behavior and checkout observations separate when reproducing the result.
Check imports, model behavior and viewing separately
The Python documentation describes low-level bindings close to the C API. That interface suits custom simulation loops. A researcher seeking ready-made learning tasks may need an environment layer instead.
For another evaluation, first record the installed distribution versions and confirm that the bindings import. Next, load a small representative model and check its state progression before adding a controller or viewer. These are proposed acceptance checks; this review did not execute them successfully.
Viewing introduces its own requirements. In the documented passive mode, the calling script remains responsible for timing and advancing physics state. On macOS, that mode requires the mjpython launcher. These are documented constraints, not an explanation for our missing-core error. No documentation example was executed for this correction.
Choose an alternative by the layer you need
Bullet's README recommends PyBullet Python bindings for robotics and reinforcement learning. PyBullet is a route for evaluating another engine and its API. We have no comparative simulation results or evidence that it would be easier to set up in this sandbox.
dm_control supplies reinforcement-learning environments powered by MuJoCo, along with task-composition tools. It addresses a need for environments above the engine. Its MuJoCo dependency means it does not establish an independent solution to the unresolved binding problem.
The supplied metadata records a November 7, 2026 last push, following the November 6 release. Those dates show recent repository activity; they do not establish maintainer responsiveness or support quality. The README says MuJoCo is not an officially supported Google product.
Before committing a research schedule, obtain a working import and a reproducible run of your representative model. Record the environment alongside the experiment.