Nanobot

Nanobot bundles its terminal workbench into platform wheels

Nanobot's September 15 packaging change puts the native terminal interface inside five platform wheels, removing the supported install path's first-run GitHub download and separate Bun requirement. PyPI lists the artifacts; operating-system limits and session migration still matter.

← Back to homeOriginal source ↗

Nanobot has moved an important installation dependency out of the first-run experience. A change merged on September 15 packages the native terminal workbench inside platform-specific Python wheels, and the inspected PyPI record lists the five corresponding 0.3.5 wheels. The broader release connects terminal and browser work to the same gateway and saved conversations. The news is not simply a version increment: the project is reducing the gap between installing a Python package and actually opening the interface that users are now expected to use.

The facts

- PR #5787 merged on September 15 and describes five platform wheels built from checked Python and native release artifacts. - The package registry lists macOS arm64/x64, Linux arm64/x64 and Windows amd64 wheels uploaded on September 15. - The packaging change uses Bun's baseline x64 target rather than requiring AVX2, while documenting SSE4.2, macOS 13 and glibc 2.17 boundaries. - The release notes say plain nanobot opens the native terminal interface; the classic Python prompt remains separately selectable. - The release moves session JSONL storage under the configuration directory and warns against old and new processes writing the same workspace concurrently.

Why it matters

First-run downloads are operational dependencies even when they are absent from a package manager's installation report. Bundling a matched interface makes offline preparation and repeatable installation easier to reason about, but it replaces one universal artifact with several platform-specific ones. Release operators now have an architecture and licensing matrix to maintain. Users gain a more coherent front door to the existing runtime, not a second independent agent engine. That distinction matters when switching between the browser and terminal: continuity is valuable only if session storage and gateway ownership remain clear.

Current

Inspected on 2026-09-16. The Nanobot stable-channel baseline is v0.3.5 published 2026-09-15T19:05:37Z. The primary source was merged 2026-09-15T18:38:35Z when captured. Mainline merges, open proposals and packaged releases are distinct availability states; the release baseline does not establish that a proposal has shipped.

Evidence

Primary evidence: HKUDS/nanobot PR #5787 (https://github.com/HKUDS/nanobot/pull/5787). Supporting context: Nanobot — terminal workbench and upgrade notes (https://github.com/HKUDS/nanobot/releases/tag/v0.3.5); Nanobot — official product README (https://raw.githubusercontent.com/HKUDS/nanobot/main/README.md). The source bodies and linked context were inspected. Test results quoted from contributors remain attributed reports, not independently reproduced experiments.

Operator take

Check the wheel selected for the actual target host and rehearse a session-backed upgrade with a copy of state. The release's instruction to stop old writers before migration is more consequential than the launcher shortcut. Keep rollback instructions beside the backup, including the documented restore-workspace path, rather than assuming a package downgrade reverses data movement. Treat the author's macOS smoke as scoped evidence, not native execution proof for every operating system. For deployment automation, verify artifact presence and launch behavior separately; a registry upload establishes distribution, not a successful terminal session on the fleet.

Caveat

The source reports 63 Python packaging tests and 234 TUI tests, with a macOS arm64 install smoke. Its Linux/Windows native-CI requirement must not be replaced by architecture inspection. Tests were not independently rerun here, and the registry is private corroboration rather than an extra news item.

The source reports 63 Python packaging tests and 234 TUI tests, with a macOS arm64 install smoke. Its Linux/Windows native-CI requirement must not be replaced by architecture inspection. Tests were not independently rerun here, and the registry is private corroboration rather than an extra news item.