Make ward agent logs reflect live run output #965

New issue

Closed

opened 2026-07-10 07:50:53 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-10 07:50:53 +00:00

Member

Problem

During the director burn-down on 2026-07-10, ward agent logs coilyco-flight-deck/ward#964 --tail ... repeatedly returned only the wrapper line:

ward agent logs: using docker logs engineer-codex-ward-964 --tail 200

Kai confirmed the ward#964 engineer was definitely working at the same time, so empty docker logs output was a visibility failure, not proof the run was stuck.

The same pattern appeared for cli-guard#216: the container was listed as running, but ward agent logs showed no agent output for long stretches. This makes directors guess whether a run is wedged, and caused an avoidable stop/relaunch decision on cli-guard#216.

Scope

Determine where Codex/engineer output is actually going when docker logs is empty.
Make ward agent logs surface useful live output for a running engineer, or explicitly report that the harness output is unavailable and name the alternate log location.
If brokered dispatch logs and container logs are separate surfaces, expose both or document the split in command output.
Add a regression test around the no-output case so an empty log stream cannot be mistaken for healthy visibility.

Acceptance

A director can distinguish "container alive but no output yet" from "output exists somewhere else but ward is not showing it".
ward agent logs <ref> gives enough information to follow a working run without host filesystem access.
The fix avoids using empty docker logs as the sole signal for run progress.

Filed from the read-only AOS director session after Kai confirmed ward#964 was working despite empty ward agent logs output.

## Problem During the director burn-down on 2026-07-10, `ward agent logs coilyco-flight-deck/ward#964 --tail ...` repeatedly returned only the wrapper line: ```text ward agent logs: using docker logs engineer-codex-ward-964 --tail 200 ``` Kai confirmed the `ward#964` engineer was definitely working at the same time, so empty `docker logs` output was a visibility failure, not proof the run was stuck. The same pattern appeared for `cli-guard#216`: the container was listed as running, but `ward agent logs` showed no agent output for long stretches. This makes directors guess whether a run is wedged, and caused an avoidable stop/relaunch decision on `cli-guard#216`. ## Scope * Determine where Codex/engineer output is actually going when `docker logs` is empty. * Make `ward agent logs` surface useful live output for a running engineer, or explicitly report that the harness output is unavailable and name the alternate log location. * If brokered dispatch logs and container logs are separate surfaces, expose both or document the split in command output. * Add a regression test around the no-output case so an empty log stream cannot be mistaken for healthy visibility. ## Acceptance * A director can distinguish "container alive but no output yet" from "output exists somewhere else but ward is not showing it". * `ward agent logs <ref>` gives enough information to follow a working run without host filesystem access. * The fix avoids using empty `docker logs` as the sole signal for run progress. Filed from the read-only AOS director session after Kai confirmed `ward#964` was working despite empty `ward agent logs` output.

coilyco-ops commented

2026-07-10 07:51:02 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-965 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T07:51:01Z). 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#965 · branch issue-965 · harness codex · workflow pull-requests
Run: engineer-codex-ward-965 · ward v0.555.0 · dispatched 2026-07-10T07:51:01Z
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.555.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-965` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T07:51:01Z). 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#965` · branch `issue-965` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-ward-965` · ward `v0.555.0` · dispatched `2026-07-10T07:51:01Z` - **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.555.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-10 08:02:09 +00:00

Make ward agent logs reflect live run output #967

coilyco-ops commented

2026-07-10 08:03:44 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-requests; review summary: skipped because --skip-preflight / --no-preflight also skips review.
felt: straightforward after isolating the separate live transcript surface.
confidence: high.
surprises: docker logs was only half the story; the live transcript tree was the missing path.
follow-ups: none.

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-requests; review summary: skipped because --skip-preflight / --no-preflight also skips review. felt: straightforward after isolating the separate live transcript surface. confidence: high. surprises: `docker logs` was only half the story; the live transcript tree was the missing path. follow-ups: none. </details>

coilyco-ops closed this issue

2026-07-10 08:08:02 +00:00