Cross-owner forwarded dispatch can still report success without a visible worker #1096

New issue

Closed

opened 2026-07-10 22:42:33 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-10 22:42:33 +00:00

Member

Problem

After ward#1087 closed, forwarded dispatches for coilyco-flight-deck repos now become visible again, but coilysiren/website#66 still does not.

Evidence from the director surface on 2026-07-10:

warded engineer coilyco-flight-deck/ward#1086 --harness codex ... forwarded, then appeared as engineer-codex-ward-1086 in ward agent list after a longer propagation wait.
warded engineer coilyco-flight-deck/agentic-os#454 --harness codex ... forwarded, then appeared as engineer-codex-agentic-os-454.
warded engineer coilysiren/website#66 --harness codex forwarded successfully but never appeared in ward agent list.
A second retry with --harness claude also forwarded successfully but never appeared in ward agent list.

This looks narrower than the original forwarded-dispatch visibility bug: cross-owner or coilysiren repo dispatch can still report forwarded success without a visible worker.

Task

Make forwarded dispatch report failure, or make the worker visible, for coilysiren/website#66 style dispatches. The fix should cover both Codex and Claude harness launches.

Done

A forwarded warded engineer coilysiren/website#66 --harness codex either produces a visible worker in ward agent list or reports a launch failure.
A forwarded warded engineer coilysiren/website#66 --harness claude has the same behavior.
The failure mode is not silent forwarded success with no visible worker.

## Problem After `ward#1087` closed, forwarded dispatches for coilyco-flight-deck repos now become visible again, but `coilysiren/website#66` still does not. Evidence from the director surface on 2026-07-10: * `warded engineer coilyco-flight-deck/ward#1086 --harness codex ...` forwarded, then appeared as `engineer-codex-ward-1086` in `ward agent list` after a longer propagation wait. * `warded engineer coilyco-flight-deck/agentic-os#454 --harness codex ...` forwarded, then appeared as `engineer-codex-agentic-os-454`. * `warded engineer coilysiren/website#66 --harness codex` forwarded successfully but never appeared in `ward agent list`. * A second retry with `--harness claude` also forwarded successfully but never appeared in `ward agent list`. This looks narrower than the original forwarded-dispatch visibility bug: cross-owner or coilysiren repo dispatch can still report forwarded success without a visible worker. ## Task Make forwarded dispatch report failure, or make the worker visible, for `coilysiren/website#66` style dispatches. The fix should cover both Codex and Claude harness launches. ## Done * A forwarded `warded engineer coilysiren/website#66 --harness codex` either produces a visible worker in `ward agent list` or reports a launch failure. * A forwarded `warded engineer coilysiren/website#66 --harness claude` has the same behavior. * The failure mode is not silent forwarded success with no visible worker.

coilyco-ops added the

headless

labels

2026-07-10 22:42:33 +00:00

coilyco-ops commented

2026-07-10 22:42:55 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-1096 on host KAI-DESKTOP-TOWER.

Reserved by ward agent --harness codex (reserved 2026-07-10T22:42:53Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#1096 · branch issue-1096 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-1096 · ward v0.605.0 · dispatched 2026-07-10T22:42:53Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.605.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-1096` on host `KAI-DESKTOP-TOWER`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T22:42:53Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#1096` · branch `issue-1096` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-1096` · ward `v0.605.0` · dispatched `2026-07-10T22:42:53Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.605.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-10 22:50:16 +00:00

Cross-owner forwarded dispatch can still report success without a visible worker #1097

coilyco-ops commented

2026-07-10 22:51:20 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-request-and-merge; review summary: skipped because the in-container review gate was intentionally skipped for temporary ward default pending brokered QA.

Retrospective: the fix stayed small. The key was proving the false-success path with a same-name, wrong-owner container and switching the broker to the exact owner/repo/issue labels.

Confidence: high.

Surprises: the repo-wide ward exec test run hit unrelated cmd/ward failures, but the dispatch-broker slice and pre-commit both stayed green.

Follow-ups: wait for the director merge lane to land PR #1097.

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped because the in-container review gate was intentionally skipped for temporary ward default pending brokered QA. Retrospective: the fix stayed small. The key was proving the false-success path with a same-name, wrong-owner container and switching the broker to the exact owner/repo/issue labels. Confidence: high. Surprises: the repo-wide `ward exec test` run hit unrelated `cmd/ward` failures, but the dispatch-broker slice and pre-commit both stayed green. Follow-ups: wait for the director merge lane to land PR #1097. </details>

coilyco-ops closed this issue

2026-07-10 22:54:44 +00:00