v0.1.1 — Windows joins

Three files, one per platform. All are self-contained: each carries a minimal Rust toolchain and the JavaScript runtime, so the first app can be built on a machine with nothing installed beyond the OS and its C toolchain.

Platform	File	Notes
macOS arm64	Deepnest-0.1.1-arm64-mac.dmg	ad-hoc signed, not notarized — right-click → Open the first time
Windows x64	Deepnest-0.1.1-x64-windows.exe	not signed at all — SmartScreen asks once; one file, nothing to install
Linux x64	Deepnest-0.1.1-x64-linux.tar.gz	not signed at all; a tarball because that is the archive format that carries the executable bit — glibc, not musl

A .sha256 sits beside each download.

The Linux download holds one file, deepnest: extract it and run it. It is built against glibc and carries the glibc build of the JavaScript runtime, so a musl-only distribution such as Alpine is not covered yet.

What the Windows build does not do yet

The agent's bash tool refuses to run a command on Windows. Confinement there is an ACL plan plus a restricted token: the plan is derived, the code that applies it is not written, and a plan derived but never applied is no fence at all — so the call is refused rather than run unconfined. File tools, app builds and app runs do not go through that path and work.

A defect this fixes on macOS

v0.1.0's disk image never passed codesign --verify --strict. The linker ad-hoc signs the executable, and an arm64 executable's signature declares a resource seal the .app never had, so a strict verify failed with code has no resources but signature indicates they must be present. The bundle is now re-sealed with codesign --force --sign -, which writes Contents/_CodeSignature/CodeResources, and the strict verify is an acceptance condition on both the signed and the unsigned path instead of the signed one only. The signature is still ad-hoc: this changes what the bundle carries, not who vouches for it.

Requirements

• macOS — Xcode Command Line Tools (xcode-select --install).
• Windows — Visual Studio C++ Build Tools.
• Linux — a C compiler and linker (build-essential on Debian/Ubuntu, base-devel on Fedora).

deepnest checks for them before the first build and walks you through installing what is missing, instead of failing halfway through compilation.

How these were built

Every file was built by CI, never from a laptop, and no job stops at "it compiled".

The macOS and Windows files were built by CI from the v0.1.1 tag. The Windows job starts the executable, asks /api/health on a port moved off 4270, and requires ~/.deepnest/deepnest.token to have been minted.

The Linux file was attached after the tag was cut, and that is stated rather than glossed over: a workflow has to reach the default branch before it can be run at all, and linux.yml landed on the default branch only after v0.1.1. It was built by CI from the commit the tag points at, with only that workflow added — the same tagged source, built by CI. Its job packs the tarball, unpacks it again, starts the executable it just packaged, asks /api/health and gets {"status":"ok","version":"0.1.1"}, and requires the token it mints to be 0600.

v0.1.0 — the first download

The first build of deepnest you can download and open. It is the app, not a promise of one: it starts, opens a page in your browser, and an agent writes a working application on your own machine — React front end, Rust back end, SQLite storage — reloading the page while it writes.

Install

1. Download Deepnest-0.1.0-arm64-mac.dmg below. Apple silicon only, macOS 12 or newer.
2. Open the disk image and drag Deepnest out of it.
3. The first launch will be refused: this build is ad-hoc signed and not notarized, because there is no Developer ID identity behind the project. Right-click the app → Open → Open again. macOS remembers the decision for that copy.

sha256 is attached beside the image as Deepnest-0.1.0-arm64-mac.dmg.sha256.

Before your first build, deepnest checks for the platform's C toolchain — Xcode Command Line Tools on macOS (xcode-select --install) — and walks you through installing it, rather than failing halfway through a compilation.

What works

• The binary is self-contained: it carries a minimal Rust toolchain (1.95.0) and the JavaScript runtime (Bun 1.2.21), and unpacks them on first launch, so an app can be built on a machine with nothing installed but the OS and its C toolchain.
• http://127.0.0.1:4270/ serves the page and opens it in your desktop browser. The control token is written to ~/.deepnest/deepnest.token, mode 0600.
• Every app is a directory under ~/.deepnest/apps/<slug>/: source, config, SQLite database and build output together. There is no remote build server and no cloud account.
• Every app has its own agent, in a dialog beside it. It generates and modifies the code, and the page reloads while it works.
• Every tool call runs inside an OS-level sandbox — Seatbelt on macOS — with three modes; protected files are unwritable in all of them.
• A model endpoint over https works, verified against the machine's own certificate store. Skills load from ~/.deepnest/skills/<name>/SKILL.md.

What does not work yet

• macOS arm64 only. There is no Windows build and no Linux build. Both back ends are in the repository and both are exercised in CI on every change; what is missing is the packaging, not the platform. Building from source works on all three today.
• No Developer ID, no notarization, no secure timestamp. The bundle is ad-hoc signed, which is why the first open needs a right-click. A signed build needs a certificate and an app-specific password that no runner holds yet.
• A model endpoint is required. Nothing is built until base_url / key / model are filled in on the first-run form. The binary carries the toolchain, not a model, and there is no bundled local model.
• No auto-update, no crash reporting, no telemetry of any kind. Nothing leaves your machine except what you send to the endpoint you configured yourself.

What is inside the app

The toolchain travels inside the binary rather than beside it: a packed archive (138,749,755 bytes; Rust toolchain compressed from 486 MB, JavaScript runtime from 60 MB) is embedded at build time and unpacked to the app's own directory on first use. The executable is 145,616,912 bytes; the disk image is ~136 MB.

Built from tag v0.1.0 on a CI runner — never from a laptop.