kami/orchestra
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Record the pane-environment and herdr findings that block flow 1

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
kami
2026-08-26 18:41:36 +04:00
parent 69f630a5f1
commit 7e1140d248
2 changed files with 63 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AUDIT.md
+28
View File
@@ -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.
BURNIN.md
+35
View File
@@ -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_<ID>`) 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