Investigate Codex director surface using medium effort despite high role overlay #897

New issue

Closed

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

coilyco-ops commented

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

Member

Problem

A Codex director surface is visible as medium effort even though the aos fleet spec sets the Codex director and advisor role overlays to reasoning-effort high:

https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/src/branch/main/.ward/ward-kdl.fleet.kdl#L72

This may mean the director surface was not launched with the selected aos WARD_CONFIG_REF, the role overlay is not applied to surfaced Codex sessions, or the resolved effort is not propagated into the Codex invocation/UI metadata.

Do

Trace how a director surface resolves Codex model-context config from the effective fleet:
- selected config source / WARD_CONFIG_REF
- flat Codex default
- per-role overlay for director
- WARD_CODEX_REASONING_EFFORT / --config override precedence
Check the launch path for director surfaces specifically, not only detached engineer containers.
Verify what gets printed in the startup config echo and what env/argv reaches Codex.
Determine whether dispatched engineers are expected to stay medium because the linked overlay applies only to director and advisor.
Fix the bug if ward is dropping the director/advisor overlay or failing to forward the resolved effort to Codex.
If the behavior is correct but the UI label is misleading, document the exact boundary and add the smallest test/doc update that prevents future confusion.

Acceptance

A test covers Codex effort resolution for a director surface or the closest launch planner responsible for it.
The investigation result names which config source was used and where the effort value changed or was preserved.
ward exec test passes, or the issue comment names the exact failing check.

Closes this issue when merged.

## Problem A Codex director surface is visible as `medium` effort even though the aos fleet spec sets the Codex `director` and `advisor` role overlays to `reasoning-effort high`: https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/src/branch/main/.ward/ward-kdl.fleet.kdl#L72 This may mean the director surface was not launched with the selected aos `WARD_CONFIG_REF`, the role overlay is not applied to surfaced Codex sessions, or the resolved effort is not propagated into the Codex invocation/UI metadata. ## Do - Trace how a director surface resolves Codex model-context config from the effective fleet: - selected config source / `WARD_CONFIG_REF` - flat Codex default - per-role overlay for `director` - `WARD_CODEX_REASONING_EFFORT` / `--config` override precedence - Check the launch path for director surfaces specifically, not only detached engineer containers. - Verify what gets printed in the startup config echo and what env/argv reaches Codex. - Determine whether dispatched engineers are expected to stay medium because the linked overlay applies only to `director` and `advisor`. - Fix the bug if ward is dropping the director/advisor overlay or failing to forward the resolved effort to Codex. - If the behavior is correct but the UI label is misleading, document the exact boundary and add the smallest test/doc update that prevents future confusion. ## Acceptance - A test covers Codex effort resolution for a director surface or the closest launch planner responsible for it. - The investigation result names which config source was used and where the effort value changed or was preserved. - `ward exec test` passes, or the issue comment names the exact failing check. Closes this issue when merged.

coilyco-ops commented

2026-07-10 00:40:06 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T00:40:04Z). 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#897 · branch issue-897 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-897 · ward v0.543.0 · dispatched 2026-07-10T00:40:04Z
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.543.0).

— Codex, via ward agent

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

coilyco-ops added the

headless

labels

2026-07-10 00:41:31 +00:00

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

2026-07-10 00:47:37 +00:00

fix: sync codex director overlay #901

coilyco-ops referenced this issue

2026-07-10 00:49:21 +00:00

Repair ward PR merge queue from failed prior runs #903

coilyco-ops referenced this issue

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

fix: sync codex director overlay #901

coilyco-ops closed this issue

2026-07-10 00:56:12 +00:00

coilyco-ops commented

2026-07-10 00:56:44 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skip state
review gate: intentionally skipped because ~/.ward/config.yaml default skipped it
felt: mostly config sync plus one merge-base cleanup
confidence: high
surprises: Forgejo mergeability lagged behind the status check
follow-ups: none

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skip state review gate: intentionally skipped because `~/.ward/config.yaml` default skipped it felt: mostly config sync plus one merge-base cleanup confidence: high surprises: Forgejo mergeability lagged behind the status check follow-ups: none </details>