Restore director-surface Docker socket access for reap and dispatch #1001

New issue

Closed

opened 2026-07-10 09:59:02 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

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

Member

Problem

A read-only director surface tried to free stale capacity during the infrastructure#520 loop with:

ward agent reap

The command failed inside the surface with:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
ward: list running engineer containers: exit status 1

The composed director-surface doctrine says the host Docker socket is mounted so the surface can dispatch sibling runs, and says socket permission failures were handled by ward#319. ward#319 is closed, but this current surface still cannot run Ward's Docker-backed reaper path.

This matters for the first-run loop because the pool is at the global engineer limit, engineer-goose-infrastructure-520 is stuck after terminal Goose output, and the surface cannot use Ward's supported stale-run cleanup path to free capacity.

Acceptance

In a read-only director surface, ward agent reap can connect to the intended Docker endpoint and list/reap stale engineer containers.
The same surface can still dispatch sibling warded engineer ... runs without a Docker socket access failure.
The fix covers the current surface shape, not only legacy explore containers from ward#319.
If Docker access is intentionally unavailable, the surface seed text and command error explain that reaping is unsupported instead of claiming the socket is mounted.
Tests or a container-entrypoint fixture cover the Docker endpoint exposed to the dropped agent user.

## Problem A read-only director surface tried to free stale capacity during the infrastructure#520 loop with: ```text ward agent reap ``` The command failed inside the surface with: ```text Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? ward: list running engineer containers: exit status 1 ``` The composed director-surface doctrine says the host Docker socket is mounted so the surface can dispatch sibling runs, and says socket permission failures were handled by ward#319. ward#319 is closed, but this current surface still cannot run Ward's Docker-backed reaper path. This matters for the first-run loop because the pool is at the global engineer limit, `engineer-goose-infrastructure-520` is stuck after terminal Goose output, and the surface cannot use Ward's supported stale-run cleanup path to free capacity. ## Acceptance * In a read-only director surface, `ward agent reap` can connect to the intended Docker endpoint and list/reap stale engineer containers. * The same surface can still dispatch sibling `warded engineer ...` runs without a Docker socket access failure. * The fix covers the current surface shape, not only legacy explore containers from ward#319. * If Docker access is intentionally unavailable, the surface seed text and command error explain that reaping is unsupported instead of claiming the socket is mounted. * Tests or a container-entrypoint fixture cover the Docker endpoint exposed to the dropped agent user. Related: coilyco-flight-deck/infrastructure#520, coilyco-flight-deck/ward#319, and coilyco-flight-deck/ward#990.

coilyco-ops added the

headless

labels

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

coilyco-ops commented

2026-07-10 09:59:10 +00:00

Author

Member

WARD-DISPATCH: deferred ⏸

deferred details

This forwarded dispatch was deferred after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#1001 --harness codex --ward-version v0.573.0
Container: engineer-codex-ward-1001
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T095907Z-director-codex-vg55-coilyco-flight-deck-ward-1001.log
Capacity: ward agent engineer --harness codex: global engineer limit is reached: 12 running (limit 12); wait for a run to finish or run ward agent reap for stale engineers

Retry: the issue stays queued and the director will try again when a slot opens.

— Codex, via ward agent

WARD-DISPATCH: deferred ⏸ <details><summary>deferred details</summary> This forwarded dispatch was deferred after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#1001 --harness codex --ward-version v0.573.0` Container: `engineer-codex-ward-1001` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T095907Z-director-codex-vg55-coilyco-flight-deck-ward-1001.log` Capacity: `ward agent engineer --harness codex: global engineer limit is reached: 12 running (limit 12); wait for a run to finish or run `ward agent reap` for stale engineers` Retry: the issue stays queued and the director will try again when a slot opens. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 10:00:23 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T10:00:22Z). 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#1001 · branch issue-1001 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-1001 · ward v0.573.0 · dispatched 2026-07-10T10:00:22Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T09:59:10Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-1001` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T10:00:22Z). 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#1001` · branch `issue-1001` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-1001` · ward `v0.573.0` · dispatched `2026-07-10T10:00:22Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T09:59:10Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.573.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-10 10:16:03 +00:00

Restore director-surface Docker socket access for reap and dispatch #1010