dispatch help text says 'refuses outside coilysiren/*' but runtime accepts all primary orgs #67

Closed
opened 2026-06-04 10:06:19 +00:00 by coilysiren · 1 comment
Owner

dispatch help text says "refuses anything outside the coilysiren/* org" — multi-org-aware refusal already accepts coilyco-bridge/* + coilyco-flight-deck/*

The runtime gate (Config.ownerAllowed) accepts AllowedOwner plus every entry in AllowedOwners. Coily passes all three primary orgs (coilysiren, coilyco-bridge, coilyco-flight-deck) via AllowedOwners: r.primaryOrgs(), and dispatch correctly accepts a coilyco-bridge/coily#1 ref (refusing only because that issue is closed).

But the help text on both dispatch and dispatch headless interpolates d.cfg.AllowedOwner (single owner) into the "refuses anything outside the X/* org" sentence (dispatch.go:187 and dispatch.go:245). Operators reading the help reasonably conclude that coilyco-* refs will be refused and avoid using them.

Fix

Swap the format-string substitution from d.cfg.AllowedOwner to d.cfg.allowedOwnersLabel() — the same helper used in the actual refusal message at dispatch.go:421. The label renders coilysiren/* for single-owner and {coilysiren, coilyco-bridge, coilyco-flight-deck}/* for multi-owner.

Where this came up

A Claude Code session in the Kapwing workdir read the misleading help text, told the operator that coilyco-* repos were out of scope for dispatch, and tried to pull the operator into widening the gate (which was already wide). Confirmed otherwise only after probing with a real ref.

## `dispatch` help text says "refuses anything outside the coilysiren/* org" — multi-org-aware refusal already accepts coilyco-bridge/* + coilyco-flight-deck/* The runtime gate (`Config.ownerAllowed`) accepts `AllowedOwner` plus every entry in `AllowedOwners`. Coily passes all three primary orgs (`coilysiren`, `coilyco-bridge`, `coilyco-flight-deck`) via `AllowedOwners: r.primaryOrgs()`, and dispatch correctly accepts a `coilyco-bridge/coily#1` ref (refusing only because that issue is closed). But the help text on both `dispatch` and `dispatch headless` interpolates `d.cfg.AllowedOwner` (single owner) into the "refuses anything outside the X/* org" sentence (dispatch.go:187 and dispatch.go:245). Operators reading the help reasonably conclude that coilyco-* refs will be refused and avoid using them. ### Fix Swap the format-string substitution from `d.cfg.AllowedOwner` to `d.cfg.allowedOwnersLabel()` — the same helper used in the actual refusal message at dispatch.go:421. The label renders `coilysiren/*` for single-owner and `{coilysiren, coilyco-bridge, coilyco-flight-deck}/*` for multi-owner. ### Where this came up A Claude Code session in the Kapwing workdir read the misleading help text, told the operator that coilyco-* repos were out of scope for dispatch, and tried to pull the operator into widening the gate (which was already wide). Confirmed otherwise only after probing with a real ref.
coilysiren added
P3
and removed
P2
labels 2026-06-17 08:39:58 +00:00
Author
Owner

🔒 Reserved by ward agent claude — container ward-cli-guard-issue-67-claude-81d7f53c on host kais-macbook-pro.local is carrying this issue (reserved 2026-06-18T07:30:11Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

<!-- ward-agent-reservation --> 🔒 Reserved by `ward agent claude` — container `ward-cli-guard-issue-67-claude-81d7f53c` on host `kais-macbook-pro.local` is carrying this issue (reserved 2026-06-18T07:30:11Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. <!-- ward-agent-signature --> — Claude (she/her), via `ward agent`
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/cli-guard#67
No description provided.