You should be able to set WARD_CONFIG_REF via ~/.ward/config.yaml #1489

New issue

Closed

opened 2026-07-21 01:13:55 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-07-21 01:13:55 +00:00

Owner

No description provided.

coilyco-ops commented

2026-07-21 02:20:59 +00:00

Member

Field report in support of this. Fresh papercut from a live session, brew ward v0.775.0 on macOS.

warded director --agent claude from the flight-deck workspace refused with:

refusing untrusted owner "coilyco-flight-deck" (allowed: coilysiren)

Root cause chain:

WARD_CONFIG_REF was unset, so the runner fell back to the baked neutral defaults, whose repo-authority block trusts only coilysiren.
The director scope came from ~/.ward/config.yaml (director.default-scope: coilyco-flight-deck, coilyco-gaming), so the operator config already named coilyco targets while the config source silently stayed baked.
The selectedConfigRef() coilyco reconstruction only fires when WARD_TARGET_OWNER / WARD_TARGET_REPO are in the env, which is never true for a hand-launched interactive director. So the one launch mode a human uses most is the one that cannot self-heal its config source.

The fix was a one-liner once found (export WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os//.ward), but finding it took reading configsource.go. ~/.ward/config.yaml is already the file the director reads its scope from, so it is the natural home for the bundle ref too. A config key here would have turned an hour of source spelunking into zero.

Related papercut worth folding in: ward doctor under baked defaults fails its ops-bundle check (missing top-level wrap ops forgejo block), so the diagnostic surface reads as broken in exactly the misconfigured state where a user needs it to explain what is wrong.

Filed by Claude Code during a trust-gate debugging session with Kai.

Field report in support of this. Fresh papercut from a live session, brew ward v0.775.0 on macOS. `warded director --agent claude` from the flight-deck workspace refused with: refusing untrusted owner "coilyco-flight-deck" (allowed: coilysiren) Root cause chain: 1. `WARD_CONFIG_REF` was unset, so the runner fell back to the baked neutral defaults, whose repo-authority block trusts only `coilysiren`. 2. The director scope came from `~/.ward/config.yaml` (`director.default-scope: coilyco-flight-deck, coilyco-gaming`), so the operator config already named coilyco targets while the config source silently stayed baked. 3. The `selectedConfigRef()` coilyco reconstruction only fires when `WARD_TARGET_OWNER` / `WARD_TARGET_REPO` are in the env, which is never true for a hand-launched interactive director. So the one launch mode a human uses most is the one that cannot self-heal its config source. The fix was a one-liner once found (`export WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os//.ward`), but finding it took reading configsource.go. `~/.ward/config.yaml` is already the file the director reads its scope from, so it is the natural home for the bundle ref too. A config key here would have turned an hour of source spelunking into zero. Related papercut worth folding in: `ward doctor` under baked defaults fails its ops-bundle check (`missing top-level wrap ops forgejo block`), so the diagnostic surface reads as broken in exactly the misconfigured state where a user needs it to explain what is wrong. Filed by Claude Code during a trust-gate debugging session with Kai.

coilyco-ops referenced this issue

2026-07-21 02:20:59 +00:00

Evaluate, and likely remove, trust gate feature #1487

coilyco-ops referenced this issue

2026-07-22 08:41:47 +00:00

Audit and remove remaining baked coilyco fleet configuration from ward #1498

coilyco-ops referenced this issue from a commit

2026-07-22 10:28:56 +00:00

feat(config): read operator config source (closes #1489)

coilyco-ops closed this issue

2026-07-22 10:28:56 +00:00