From 7e1140d248dd75229723a35e0507e9942ecf3310 Mon Sep 17 00:00:00 2001 From: kami Date: Wed, 26 Aug 2026 18:41:36 +0400 Subject: [PATCH] Record the pane-environment and herdr findings that block flow 1 Co-Authored-By: Claude Opus 5 --- AUDIT.md | 28 ++++++++++++++++++++++++++++ BURNIN.md | 35 +++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+) diff --git a/AUDIT.md b/AUDIT.md index c9146f8..2a2defe 100644 --- a/AUDIT.md +++ b/AUDIT.md @@ -363,3 +363,31 @@ one deployed. Not done, and both need root: the `/etc/orchestra/worker.env` scrub (mode 0600, root-owned) and its in-pane verification. No agent should run before that. + +## Pane environment and the opencode backend, probed 2026-08-26 18:45 + +Three findings, all blocking flow 1, none of them code defects in this session's +work. + +- **herdr is not running on workpc.** `herdr status server` reports `not + running`; the socket refuses connections and its log stops at 2026-07-30. + `workpc-opencode` cannot start a pane. Note that the worker logs `serving + harness workpc-opencode (opencode) on herdr backend` at startup **without + touching the socket**, so that line is not evidence of reachability. Same + shape as the older note about the coordinator never logging a herdr success: + absence of an error is not evidence here either. +- **The two workpc harnesses inherit different environments.** An opencode pane + is created by the herdr daemon and inherits *herdr's* environment, so scrubbing + `/etc/orchestra/worker.env` does not affect it. A claude pane comes from + `TmuxBackend.StartAgent`, which runs `tmux new-session` via + `exec.CommandContext` with no `Env` set, so the tmux server inherits the + worker's full environment and every pane under it does too. +- **The scrub alone cannot close the tmux path.** The worker needs + `ORCHESTRA_WORKER_TOKEN*` and `ORCHESTRA_FEDERATION_ADMIT_TOKEN` to function, + and the pane inherits exactly those. Closing it needs a filtered `cmd.Env` in + the backend, or a tmux server started separately with a clean environment. + Deliberately not built now: flow 1 is opencode only, and the burn-in order + puts claude at step 6. + +Sudo is not available in this sandbox, so the worker install, the restart, and +the `worker.env` scrub remain operator steps. diff --git a/BURNIN.md b/BURNIN.md index 455e607..6d1695f 100644 --- a/BURNIN.md +++ b/BURNIN.md @@ -38,8 +38,43 @@ sudo systemctl restart orchestra-worker journalctl -u orchestra-worker -n 5 --no-pager # must print revision 6f9300b... ``` +A third blocker, found while preparing the pane check: + +**herdr is not running on workpc.** `herdr status server` reports `not running`, +the socket at `/home/kami/.config/herdr/herdr.sock` refuses connections, and its +log stops at 2026-07-30. `workpc-opencode` therefore cannot start a pane, even +with the worker installed. The worker logs `serving harness workpc-opencode +(opencode) on herdr backend` at startup without touching the socket, so that +line is not evidence the backend is reachable. herdr is an interactive terminal +workspace manager: running `herdr` in a terminal launches or attaches to the +persistent session and starts the server. Confirm with `herdr status server` +before creating a task. + Then scrub the pane environment before letting an agent run. +### Where the pane environment actually comes from + +The two workpc harnesses inherit different environments, so one scrub does not +cover both. + +- **`workpc-opencode` (herdr backend).** The pane is created by the herdr + daemon, which is a separate long-running process. It inherits herdr's + environment, not the worker's. Scrubbing `worker.env` does nothing here. + Whatever environment herdr is started with is what every opencode pane gets. +- **`workpc-claude` (tmux backend).** `TmuxBackend.StartAgent` runs `tmux + new-session` through `exec.CommandContext` with no `Env` set + (`internal/herdr/tmux.go`). If the tmux server is not already up, the worker + starts it, and that server inherits the worker's full environment. Every + claude pane then inherits it too. + +This exposes a conflict the scrub alone cannot resolve. The worker legitimately +needs `ORCHESTRA_WORKER_TOKEN` (or `ORCHESTRA_WORKER_TOKEN_`) and +`ORCHESTRA_FEDERATION_ADMIT_TOKEN`, and deleting them breaks the worker. Keeping +them means the tmux path hands them to the agent. Closing it needs either a +filtered `cmd.Env` when the backend spawns a pane, or a tmux server started +separately with a clean environment. Not on flow 1's path, because flow 1 is +opencode only. Close it before step 6. + ## Baseline: one harness, one path `workpc-opencode` only. Codex is a coverage gap, not a prerequisite, and no