Proxmox gives a new guest x86-64-v2-AES by default, which tops out at SSE4.2 and carries no AVX. dejima now supports Cline as a second agent harness, and Cline's CLI ships as a Bun-embedded compiled binary whose stock build requires AVX2. On a default guest it dies on SIGILL, exit 132, before printing anything, and Cline publishes no baseline build to fall back to. So a devbox built from the runbook as it stood cannot run one of dejima's two supported harnesses, and the symptom is a silent crash.
This is a VM-creation setting rather than anything the guest can fix from inside, which is why it belongs on the node-side runbook and not in docs/building-a-devbox.md.
The change is confined to proxmox/README.md §2: a CPU Type row in the creation table asking for x86-64-v3 or better, and a note under it covering the three ways this goes wrong. host works too but pins the guest to the exact CPU of the node it was created on and breaks live migration, so x86-64-v3 is named as the portable floor that still carries AVX2. A cpu: <model>,flags=... allowlist cannot add AVX2, since the flag list only toggles a small fixed set, so it has to be the model. And changing it on an existing VM needs a full stop and start, because a reboot issued inside the guest keeps the same QEMU process and therefore the same CPU model, which reads as the setting not having taken.
The note ends with a grep -qw avx2 /proc/cpuinfo check, phrased so it is also worth running on a devbox created before this section existed. Without it, an already-wrong guest is discovered by a crash with no output rather than by a check.
Nothing else in the repository referenced the VM's CPU, so no other document, script or test needed to move.
Tested: the full bats test/ suite passes, 98 of 98, including links.bats, which is the one that would catch a broken relative link or an orphaned anchor in the edited prose. The technical claims come from the handoff note, where they were established by running Cline on a guest before and after the CPU type was changed: SIGILL before, working after.
**Summary generated by LLM agent**
Proxmox gives a new guest `x86-64-v2-AES` by default, which tops out at SSE4.2 and carries no AVX. dejima now supports Cline as a second agent harness, and Cline's CLI ships as a Bun-embedded compiled binary whose stock build requires AVX2. On a default guest it dies on SIGILL, exit 132, before printing anything, and Cline publishes no baseline build to fall back to. So a devbox built from the runbook as it stood cannot run one of dejima's two supported harnesses, and the symptom is a silent crash.
This is a VM-creation setting rather than anything the guest can fix from inside, which is why it belongs on the node-side runbook and not in `docs/building-a-devbox.md`.
The change is confined to `proxmox/README.md` §2: a CPU Type row in the creation table asking for `x86-64-v3` or better, and a note under it covering the three ways this goes wrong. `host` works too but pins the guest to the exact CPU of the node it was created on and breaks live migration, so `x86-64-v3` is named as the portable floor that still carries AVX2. A `cpu: <model>,flags=...` allowlist cannot add AVX2, since the flag list only toggles a small fixed set, so it has to be the model. And changing it on an existing VM needs a full stop and start, because a reboot issued inside the guest keeps the same QEMU process and therefore the same CPU model, which reads as the setting not having taken.
The note ends with a `grep -qw avx2 /proc/cpuinfo` check, phrased so it is also worth running on a devbox created before this section existed. Without it, an already-wrong guest is discovered by a crash with no output rather than by a check.
Nothing else in the repository referenced the VM's CPU, so no other document, script or test needed to move.
Tested: the full `bats test/` suite passes, 98 of 98, including `links.bats`, which is the one that would catch a broken relative link or an orphaned anchor in the edited prose. The technical claims come from the handoff note, where they were established by running Cline on a guest before and after the CPU type was changed: SIGILL before, working after.
Proxmox defaults a new guest to x86-64-v2-AES, which has no AVX. dejima
now supports Cline as a second harness, and Cline's CLI is a Bun-embedded
binary whose stock build needs AVX2: on a v2 guest it dies on SIGILL
before printing anything, with no baseline build to fall back to.
The runbook now asks for x86-64-v3 at creation time, says why not host
and why a flags allowlist cannot substitute, notes that changing it needs
a full stop/start rather than a guest reboot, and gives a /proc/cpuinfo
check for guests built before this.
This just isn't true at all. There's plenty of settings (basically all of them) that a guest can't change from the inside of the VM. On top of that, the CPU type can absolutely be changed later from the Proxmox console, just not while the guest is running. Drop the hyperbole:
AVX2 is needed if you want support for Cline. Proxmox defaults a new VM to x86-64-v2-AES, which tops out at SSE4.2 and has no AVX at all. The Cline harness's CLI ships as a Bun-embedded compiled binary whose stock build needs AVX2. You'll need a CPU type which supports AVX2 if you plan to run Cline in the VM, and the minimum CPU type which supports this is x86-64-v3.
Three ways to get this wrong:
...
This just isn't true at all. There's plenty of settings (basically all of them) that a guest can't change from the inside of the VM. On top of that, the CPU type can absolutely be changed later from the Proxmox console, just not while the guest is running. Drop the hyperbole:
> **AVX2 is needed if you want support for Cline.** Proxmox defaults a new VM to `x86-64-v2-AES`, which tops out at SSE4.2 and has no AVX at all. The Cline harness's CLI ships as a Bun-embedded compiled binary whose stock build needs AVX2. You'll need a CPU type which supports AVX2 if you plan to run Cline in the VM, and the minimum CPU type which supports this is `x86-64-v3`.
>
> Three ways to get this wrong:
...
Don't mention "two" harnesses anywhere here. That number will drift rapidly as dejima takes on new harnesses and this repo shouldn't need to be updated with each newly supported harness unless necessary.
Don't mention "two" harnesses anywhere here. That number will drift rapidly as dejima takes on new harnesses and this repo shouldn't need to be updated with each newly supported harness unless necessary.
State the requirement as Cline needing AVX2 rather than as a claim about
what a guest can fix from inside, which was both overstated and wrong:
the type is changeable from the console, just not while the VM runs.
Drop the harness count, which will drift as dejima adds harnesses.
branderson
approved these changes 2026-08-24 20:53:58 -07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary generated by LLM agent
Proxmox gives a new guest
x86-64-v2-AESby default, which tops out at SSE4.2 and carries no AVX. dejima now supports Cline as a second agent harness, and Cline's CLI ships as a Bun-embedded compiled binary whose stock build requires AVX2. On a default guest it dies on SIGILL, exit 132, before printing anything, and Cline publishes no baseline build to fall back to. So a devbox built from the runbook as it stood cannot run one of dejima's two supported harnesses, and the symptom is a silent crash.This is a VM-creation setting rather than anything the guest can fix from inside, which is why it belongs on the node-side runbook and not in
docs/building-a-devbox.md.The change is confined to
proxmox/README.md§2: a CPU Type row in the creation table asking forx86-64-v3or better, and a note under it covering the three ways this goes wrong.hostworks too but pins the guest to the exact CPU of the node it was created on and breaks live migration, sox86-64-v3is named as the portable floor that still carries AVX2. Acpu: <model>,flags=...allowlist cannot add AVX2, since the flag list only toggles a small fixed set, so it has to be the model. And changing it on an existing VM needs a full stop and start, because a reboot issued inside the guest keeps the same QEMU process and therefore the same CPU model, which reads as the setting not having taken.The note ends with a
grep -qw avx2 /proc/cpuinfocheck, phrased so it is also worth running on a devbox created before this section existed. Without it, an already-wrong guest is discovered by a crash with no output rather than by a check.Nothing else in the repository referenced the VM's CPU, so no other document, script or test needed to move.
Tested: the full
bats test/suite passes, 98 of 98, includinglinks.bats, which is the one that would catch a broken relative link or an orphaned anchor in the edited prose. The technical claims come from the handoff note, where they were established by running Cline on a guest before and after the CPU type was changed: SIGILL before, working after.@@ -109,6 +109,7 @@ before you flip it rather than after.| System | Qemu Agent | ✓ — and see the note below, the tick alone does nothing || Disks | Size | 128 GB. A devbox accumulates checkouts, container images and build caches, and it is not rebuilt on a schedule to clear them || CPU | Cores | 4 || CPU | **Type** | **`x86-64-v3` or better — not the default.** See below; the default cannot run one of dejima's two harnesses |Same here "cannot run at least one of dejima's harnesses which requires AVX2 capability"
@@ -125,6 +126,35 @@ channel the agent has nothing to attach to, the Summary pane shows no address,`qm shutdown` falls back to hoping ACPI is acted on, and a snapshot of arunning VM stays crash-consistent.**The CPU type is the one setting here a guest cannot fix later from inside.**This just isn't true at all. There's plenty of settings (basically all of them) that a guest can't change from the inside of the VM. On top of that, the CPU type can absolutely be changed later from the Proxmox console, just not while the guest is running. Drop the hyperbole:
@@ -127,1 +128,4 @@**The CPU type is the one setting here a guest cannot fix later from inside.**Proxmox defaults a new VM to `x86-64-v2-AES`, which tops out at SSE4.2 and hasno AVX at all. dejima supports Cline as one of its two agent harnesses, andDon't mention "two" harnesses anywhere here. That number will drift rapidly as dejima takes on new harnesses and this repo shouldn't need to be updated with each newly supported harness unless necessary.