coilyco-flight-deck/ward

Fork 0

Update Codex launch adapter for current codex exec flags #691

New issue

Closed

opened 2026-07-08 19:38:12 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-07-08 19:38:12 +00:00

Member

Bug

ward's Codex harness launch adapter still passes --ask-for-approval, but the installed Codex CLI rejects that flag during the container prelaunch probe.

Observed failure

A Codex engineer dispatch for coilyco-flight-deck/ward#690 failed during bootstrap with:

ward-container: bootstrap prelaunch check failed: codex launch probe failed (exit 2): error: unexpected argument '--ask-for-approval' found
tip: to pass '--ask-for-approval' as a value, use '-- --ask-for-approval'
Usage: codex exec [OPTIONS] [PROMPT]
       codex exec [OPTIONS] <COMMAND> [ARGS]

The container then reaped cleanly with no residual work. The issue thread still only showed the Codex reservation, which is also covered by coilyco-flight-deck/ward#689. This issue is the specific Codex launch-shape break.

Expected behavior

ward should generate a Codex launch/probe command that matches the installed Codex CLI. If the approval flag was renamed, removed, or moved into config/env, update the adapter and tests accordingly.

Do

Inspect the current codex exec --help shape in the target environment.
Update the Codex harness adapter/prelaunch probe to stop passing unsupported --ask-for-approval.
Preserve the intended approval/sandbox behavior through the current supported Codex option or config path.
Add or update regression coverage so stale Codex CLI flags fail in ward tests before runtime.
Add a concise note to the relevant agent/harness docs if the launch contract changed.

Acceptance

ward agent ... --harness codex prelaunch probe succeeds with the installed Codex CLI.
A Codex engineer container reaches the real task prompt instead of failing at bootstrap argument parsing.
ward exec test passes.

Filed from the read-only director surface after the Codex launch probe failed on ward#690.

## Bug ward's Codex harness launch adapter still passes `--ask-for-approval`, but the installed Codex CLI rejects that flag during the container prelaunch probe. ## Observed failure A Codex engineer dispatch for coilyco-flight-deck/ward#690 failed during bootstrap with: ```text ward-container: bootstrap prelaunch check failed: codex launch probe failed (exit 2): error: unexpected argument '--ask-for-approval' found tip: to pass '--ask-for-approval' as a value, use '-- --ask-for-approval' Usage: codex exec [OPTIONS] [PROMPT] codex exec [OPTIONS] <COMMAND> [ARGS] ``` The container then reaped cleanly with no residual work. The issue thread still only showed the Codex reservation, which is also covered by coilyco-flight-deck/ward#689. This issue is the specific Codex launch-shape break. ## Expected behavior ward should generate a Codex launch/probe command that matches the installed Codex CLI. If the approval flag was renamed, removed, or moved into config/env, update the adapter and tests accordingly. ## Do * Inspect the current `codex exec --help` shape in the target environment. * Update the Codex harness adapter/prelaunch probe to stop passing unsupported `--ask-for-approval`. * Preserve the intended approval/sandbox behavior through the current supported Codex option or config path. * Add or update regression coverage so stale Codex CLI flags fail in ward tests before runtime. * Add a concise note to the relevant agent/harness docs if the launch contract changed. ## Acceptance * `ward agent ... --harness codex` prelaunch probe succeeds with the installed Codex CLI. * A Codex engineer container reaches the real task prompt instead of failing at bootstrap argument parsing. * `ward exec test` passes. Filed from the read-only director surface after the Codex launch probe failed on ward#690.

coilyco-ops commented

2026-07-08 19:38:19 +00:00

Author

Member

🔒 Reserved by ward agent --harness opencode — container engineer-opencode-ward-691 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T19:38:17Z). 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#691 · branch issue-691 · harness opencode · workflow direct-main
Run: engineer-opencode-ward-691 · ward v0.463.0 · dispatched 2026-07-08T19:38:17Z
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.463.0).

— Qwen, via ward agent

🔒 Reserved by `ward agent --harness opencode` — container `engineer-opencode-ward-691` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T19:38:17Z). 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#691` · branch `issue-691` · harness `opencode` · workflow `direct-main` - **Run:** `engineer-opencode-ward-691` · ward `v0.463.0` · dispatched `2026-07-08T19:38:17Z` - **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.463.0). </details>  — Qwen, via `ward agent`

coilyco-ops referenced this issue

2026-07-08 19:40:44 +00:00

OpenCode harness is selectable but missing from the engineer image #692

coilyco-ops commented

2026-07-08 20:59:51 +00:00

Author

Member

🔒 Reserved by ward agent --harness goose — container engineer-goose-ward-691 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T20:59:50Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL); --force overrides.

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

Resolved: coilyco-flight-deck/ward#691 · branch issue-691 · harness goose · workflow direct-main
Run: engineer-goose-ward-691 · ward v0.463.0 · dispatched 2026-07-08T20:59:50Z
Comment thread: 0 included in the pre-flight read, 1 stripped (ward's own automated comments).
- stripped: @coilyco-ops (2026-07-08T19:38:19Z)

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

— Goose, via ward agent

🔒 Reserved by `ward agent --harness goose` — container `engineer-goose-ward-691` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T20:59:50Z). 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#691` · branch `issue-691` · harness `goose` · workflow `direct-main` - **Run:** `engineer-goose-ward-691` · ward `v0.463.0` · dispatched `2026-07-08T20:59:50Z` - **Comment thread:** 0 included in the pre-flight read, 1 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-08T19:38:19Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.463.0). </details>  — Goose, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-08 21:02:23 +00:00

Update Codex launch adapter for current codex exec flags

coilyco-ops commented

2026-07-08 21:02:41 +00:00

Author

Member

⚠️ Reopened: this run's work did not land on `main`

An ephemeral ward container (goose mode) dispatched for this issue finished but its work was not merged to main, so the reaper preserved it on a branch before teardown and reopened the issue (its closes #691 never reached main). Recover from the salvage branch below.

Repo: coilyco-flight-deck/ward
Salvage branch: ward-salvage/ward-b8ccdc84
Reason: missing same-repo closing reference
Container uptime at reap: 2m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token)

Reap diagnostics

--- reap diagnostics ---
ward version:      v0.463.0
version source:    pinned via WARD_VERSION/--ward-version (v0.463.0)
HEAD:              de9e61abcc21
origin/main:       22ded3946525
ancestry:          HEAD is NOT yet on origin/main - residual work remains to land
decision gate:     missing same-repo closing reference
reason:            missing same-repo closing reference
provenance:        present
run-owned landed:  no
working tree:      clean
container uptime:  2m (baked Forgejo PAT age proxy)
--- end reap diagnostics ---

Recover

git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-b8ccdc84
git checkout -b ward-salvage/ward-b8ccdc84 FETCH_HEAD

— Goose, via ward agent

## ⚠️ Reopened: this run's work did not land on `main` An ephemeral `ward container` (goose mode) dispatched for this issue finished but its work was **not merged to `main`**, so the reaper preserved it on a branch before teardown and reopened the issue (its `closes #691` never reached `main`). Recover from the salvage branch below. - **Repo:** `coilyco-flight-deck/ward` - **Salvage branch:** `ward-salvage/ward-b8ccdc84` - **Reason:** missing same-repo closing reference - **Container uptime at reap:** 2m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token) ## Reap diagnostics ``` --- reap diagnostics --- ward version: v0.463.0 version source: pinned via WARD_VERSION/--ward-version (v0.463.0) HEAD: de9e61abcc21 origin/main: 22ded3946525 ancestry: HEAD is NOT yet on origin/main - residual work remains to land decision gate: missing same-repo closing reference reason: missing same-repo closing reference provenance: present run-owned landed: no working tree: clean container uptime: 2m (baked Forgejo PAT age proxy) --- end reap diagnostics --- ``` ## Recover ```bash git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-b8ccdc84 git checkout -b ward-salvage/ward-b8ccdc84 FETCH_HEAD ```  — Goose, via `ward agent`

coilyco-ops commented

2026-07-08 21:21:08 +00:00

Author

Member

🔒 Reserved by ward agent --harness goose — container engineer-goose-ward-691 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T21:21:07Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL); --force overrides.

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

Resolved: coilyco-flight-deck/ward#691 · branch issue-691 · harness goose · workflow direct-main
Run: engineer-goose-ward-691 · ward v0.463.0 · dispatched 2026-07-08T21:21:07Z
Comment thread: 1 included in the pre-flight read, 2 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-08T21:02:41Z)
- stripped: @coilyco-ops (2026-07-08T19:38:19Z), @coilyco-ops (2026-07-08T20:59:51Z)

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

— Goose, via ward agent

🔒 Reserved by `ward agent --harness goose` — container `engineer-goose-ward-691` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T21:21:07Z). 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#691` · branch `issue-691` · harness `goose` · workflow `direct-main` - **Run:** `engineer-goose-ward-691` · ward `v0.463.0` · dispatched `2026-07-08T21:21:07Z` - **Comment thread:** 1 included in the pre-flight read, 2 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-08T21:02:41Z) - stripped: @coilyco-ops (2026-07-08T19:38:19Z), @coilyco-ops (2026-07-08T20:59:51Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.463.0). </details>  — Goose, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-08 21:25:01 +00:00

Fix: Remove deprecated --ask-for-approval flag from Codex prelaunch check

coilyco-ops closed this issue

2026-07-08 21:25:01 +00:00