Bee state reports BUZZING with no opencode process actually running

[scuba10steve]

Summary

trowel bee status/bee list reports a bee in state BUZZING (actively running) with a hatchedAt timestamp, but no corresponding process is actually running inside the grove's devcontainer.

Repro

1. Plant a grove and install an opencode bee.
2. trowel bee list --grove <id> reports OPENCODE BUZZING <bee-id> <hatchedAt>.
3. trowel bee status --grove <id> reports swarm status BUZZING: 1.
4. Exec into the actual fruit container running for that grove and list processes — no opencode (or related) process exists. Only the devcontainer's own placeholder init (sh -c '... while sleep 1 & wait $!; do :; done') is running.

Evidence

Grove was confirmed FLOURISHING with the repo correctly cloned to /workspace (verified via direct container inspection), so provisioning itself succeeded. The bee's .opencode/ config directory exists on disk, but docker exec <container> ps aux inside the seedling shows nothing beyond the devcontainer placeholder — no opencode process was ever launched, or it exited immediately without the state being corrected.

Impact

The server-reported bee state can't be trusted to reflect whether the AI assistant is actually usable — a cultivator has no reliable signal (short of manually exec'ing into the container) that their bee isn't actually running.

Suspected area

Whatever apiary/BeeKeeper code transitions bee state to BUZZING appears to do so without confirming the launched process is actually alive (or a failure during launch isn't being caught and reflected back into the state).

[scuba10steve]

Root cause found — the binary is never installed, and the failure is silently swallowed

While adding benchmarks for the Bee adapter (#211) I reproduced this and traced it. The suspected area in the description ("state transitions to BUZZING without confirming the process is alive") is a real gap, but it's the second of two bugs. The first one is why there's no process to find.

Bug 1: INSTALL_SCRIPT_URL returns HTTP 404

OpencodeBeeKeeper.INSTALL_SCRIPT_URL points at:

https://raw.githubusercontent.com/anomalyco/opencode/main/install.sh

$ curl -sS -o /dev/null -w "%{http_code}\n" -L https://raw.githubusercontent.com/anomalyco/opencode/main/install.sh
404

The repository path appears to be wrong.

Bug 2: ensureBinaryInstalled cannot detect that failure

ensureBinaryInstalled runs the installer as a pipeline:

runner.execute("curl -fsSL " + INSTALL_SCRIPT_URL + " | sh");

A pipeline's exit status is that of its last command. curl -f does fail on 404, but sh receives empty stdin and exits 0, so the pipeline reports success:

$ curl -fsSL https://raw.githubusercontent.com/anomalyco/opencode/main/install.sh | sh; echo "pipeline exit: $?"
curl: (56) The requested URL returned error: 404
pipeline exit: 0

SshExecutor only throws on a non-zero exit code, so nothing surfaces.

How that produces the reported symptom

1. ensureBinaryInstalled → command -v opencode fails → runs the installer → reports success, installs nothing.
2. writeConfig succeeds, which is why .opencode/ exists on disk as the description notes.
3. Bee → HIBERNATING.
4. release() runs nohup opencode serve --port 4096 ... & echo $!. Because & backgrounds it, the shell prints a PID and exits 0 even though opencode does not exist. The nohup failure happens asynchronously and is never observed.
5. BeeService.releaseBee stores that PID and sets BUZZING.

So the bee reaches BUZZING with a PID that was never alive, no binary, and a valid-looking config directory — matching the evidence in the description exactly.

Suggested fixes

Bug 2 is the more important one, since it will mask any future installer breakage:

• Make the pipeline fail loudly: set -o pipefail (requires bash, not sh), or better, split it — download to a temp file, check the exit status, then execute.
• Have release() verify the process is actually alive before transitioning to BUZZING, rather than trusting echo $!. BeeKeeper.inspect() already implements exactly this check (kill -0 <pid> plus opencode --version) but is currently never called by production code — no @Scheduled health poll exists yet, so nothing ever corrects a wrong state after the fact.

Worth noting for whoever fixes this: orchard-gauge's new benchmarks work around bug 1 by SSHing a stub opencode binary into the VM, precisely so they don't measure this failure path. If the URL is fixed without also fixing bug 2, curl … | sh will overwrite that stub and the benchmarks will silently start measuring something different with no failure signal — see the note in orchard-gauge's README.